nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Confused about how Payment API and checkout are intendend to work

Tim Perry

I am working on a web page where we accept donations from users. I am using the checkout process and the transaction checkout endpoint. However, i don't see how these two pieces are intended to work together.

So a user makes a donation in the web page. I have the page set up to send the transaction token to our systems. I have a second page where i can authorize myself and process that token via the checkout transaction endpoint. These now seem to be two disconnected processes rather than one complete transaction. Is that how payment is supposed to work?

When a user makes the payment, are we really okay telling them "thanks for the donation" if the donation hasn't even been processed by our systems? It seems that it won't be processed until someone authorizes and sends the token to the endpoint.
If the user makes a payment after business hours, storing the transaction token on our system, will the token last over night or over a weekend until someone from the office can log in and process it?

We did try some examples from here that allowed us to process the transactions automatically. Basically, it's a hack around the OAuth system, where we have someone in the office authorize and then store the return key for the next user. We then swap out keys over and over again to keep the appearance of someone being logged in a long time. There's a long thread on how this system could work. For us, it worked much of the time, but it's an unstable process prone to unannounced failure, and it is certainly not the intended use of this system. So i was wondering how this setup is really intended to work.

Find more posts tagged with

Comments

Timothy Wittig

Hey Tim,

It sounds you're basically asking two questions:

1. Why/how does the Checkout process use the transaction checkout endpoint?

2. How can SKY API endpoint be called without "user at the wheel"?

Assuming that's mostly correct, I'll try to answer those questions. I'll start with the second question because it might make the answer to the second clearer.

SKY API's OAuth implementation does support calls originating from a backend service as well as those trigger by a user interaction. Someone else on this community board had a similar question, saying "I'm scratching my head a bit wondering why I'd need OAuth here given that the documentation seems to indicate it is for a given user to authorize an app to act on their behalf." That thread will go into more details on the solution, but you're right that it seems like you're "swapping out keys over and over again to keep the appearance of someone being logged in." Other SKY API users expressed similar concerns, so we rolled out a way to avoid having to continually swap out the keys.

Given that there's a way to securely issue calls from your backend service, I'll try to address your second question about the roll that the transaction checkout endpoint plays. At a high level, the Checkout workflow involves the following:

1. Your backend service calls the GET PublicKey endpoint to embed in your web page

2. Donor confirms Checkout on web page which turns around and let's Blackbaud know about the payment info

3. Checkout client side code raises event to your client side code to make a backend service request to confirm the transaction

3. Your backend service calls the POST Transaction Checkout endpoint to securely capture the funds.

You can find more on this here.

While I might not have completely answered your questions, I'm hoping this at least drives the conversation toward more useful answers for you.

Tim Perry

Neither of those two were my questions, but the answers to them are somewhat different than i had received before, so that's a start.

Your first answer, which covers OAuth, says that we can handle authentication on the back end so that a user doesn't have to authenticate themselves to make a donation. I assume this answers your question #2. In your answer, you link to a posting that starts "I'm scratching my head". That posting refers to two other postings for an answer. One of those postings is from my group and was unanswered, and the other is the one that gave us the solution that continually swapped keys. We built the key-swapping solution, but it does not work with enough reliability to be useful. The keys sometimes stop working, and that brings down the site functions until someone from my ground gets notified that there's a problem and can refresh the main token and get new access and refresh keys. This is really an unreliable system.

At the end of the paragraph, you point out that you have a new system where keys don't have to be continually swapped, and you link to a posting about the update. That posting confirms that there is a better way and gives a link to a change log. However, that change log has no information about tokens and doesn't appear to have any documentation on how the new system works. Do you have any postings on this new method of doing things? It sounds hopeful, but i don't see how to do it yet.

In your second answer, give us the rundown of how a charge gets made. I assume that's a response to your question #1. Thanks. However, this process is based on the assumption that a secure call can be made from the back system without a user having to go through the authentication process. As of yet, i don't see a viable solution to that problem. That is what prompted my separation of functions in my first posting (checkout first then checkout transaction later), and why i asked the two questions marked with bullet points.

Timothy Wittig

Hey Tim,

Apologies, I wrote "I'll start with the second question because it might make the answer to the second clearer." when I meant "I'll start with the second question because it might make the answer to the first clearer."

Additionally, you're right, that blog doesn't have a very useful link. I've reached out to the author to update it. I believe it previously linked to the Announcement: You can now preserve refresh token values when you refresh expired access tokens located in the August 2019 changelog section. It explains that we've introduced the preserve_refresh_token parameter to the token endpoint. The preserve_refesh_token parameter:

allows you to refresh access tokens with the same refresh token until the expiration date. By default, this value is set to false and each time you refresh an expired access token, you receive a new refresh token with a sliding window expiration of 365 days.

A user will still have to make the initial, one time approval for your application to access their Blackbaud data on their behalf. We typically recommend that clients create an account specifically for this purpose. Once you've done that though, you'll be able to use the same refresh token to retrieve a new access token for 365 days. To "reset" that 365 day limit you'll need to retrieve another refresh token a some point before the 365 days transpires.

Hope this helps!