Customer with Blackbaud account was able to process a payment without being invited to the payments role?
Hi there,
I have some questions about how the authentication for the Payments API works.
For one of our clients, the client admin had authorized our Sky API Application, and they had a user that logged in and was able to process a payment through the API.
What's curious in this situation is that the user account had not been invited to the “Payments” role, in fact the client had not added that role when they had started testing. Even so, the user was able to process a payment through the API.
Where this leaves me is this: Is the payments role only for our developer account to have the ability/access to connect, and what other roles/permissions/etc are factors that determine whether or not a BBMS user has access to use the Payments API with that client account?
I would like to further my understanding of the authorization so that can be communicated to clients.
Thanks,
Dylan Hochreiter
Comments
-
Hi Dylan
Only users in the Payments role can complete the required OAuth process which gets you the access tokens required to submit API requests.
If you believe this isn't working as expected, please email me directly with details on the users and client so we can investigate further.
Thanks
Mina
0 -
Hi Mina,
As you had mentioned, I sent the email with more details to see if we can figure this out.
Also, the client asked the following as well:
- Does the client need to have the Sky API console app connected or is just having our application connected sufficient?
- Is it just the Payments role that determines whether or not a user can authenticate with the Payments API, or are their other factors? For example, does a user with “Full Access” need the Payments role?
I appreciate the help with this.
Thanks,
Dylan0 -
- Does the client need to have the Sky API console app connected or is just having our application connected sufficient?
- No, it's not required to have the SKY API console application connected for your application to work. We do recommend connecting it to the environment however, since the SKY API console is required in order for you to use the "Try It" button on our endpoint reference pages.
- Is it just the Payments role that determines whether or not a user can authenticate with the Payments API, or are their other factors? For example, does a user with “Full Access” need the Payments role?
- A user must be in the Payments role in order to perform the OAuth authorization.
Mina0 - Does the client need to have the Sky API console app connected or is just having our application connected sufficient?
-
Hi Mina,
We talked with the client about all this and they had a few last questions that I would like some insight on.
Here they are:
- If they were to set up a Payments API user account for all their API usage, what would happen if the password on that user account changed? Will that invalidate any access/refresh tokens that are being stored for those users on our end? They were describing a use case where the Payments API user password would be changed every 60 days, and were wondering what effect that could have, if any.
- The client was also talking about potentially changing the security/permissions on the Payments role. The main endpoint we use is the POST Transaction endpoint. If they have the ability to change the permissions for that role, which ones would need to be enabled for that endpoint to work?
Again, appreciate the support.
Thanks,
Dylan
0 -
Hi Dylan
Happy to help! To your questions:
- Password change: We encourage all customers to set up a dedicated Payments API user account as detailed in our Getting Started guide here. This avoids any issues if people change at the organization. If for any reason the password is changed on that user account, it will NOT affect any access/refresh tokens that are already in use. The new password would be required when the token has expired and requires reauthorization via the OAuth process.
- Payments role permissions: The Payments API User role does not manage permissions at a granular endpoint level. It is intended to reflect a role that has the authorization to allow 3rd party applications process payments on behalf of the organization (i.e. via the OAuth process). Can you share what you'd be looking to achieve by changing permissions on the Payments role?
Thanks
Mina
0
Categories
- All Categories
- 6 Blackbaud Community Help
- 211 bbcon®
- 1.4K Blackbaud Altru®
- 402 Blackbaud Award Management™ and Blackbaud Stewardship Management™
- 1.1K Blackbaud CRM™ and Blackbaud Internet Solutions™
- 15 donorCentrics®
- 360 Blackbaud eTapestry®
- 2.6K Blackbaud Financial Edge NXT®
- 657 Blackbaud Grantmaking™
- 577 Blackbaud Education Management Solutions for Higher Education
- 3.2K Blackbaud Education Management Solutions for K-12 Schools
- 941 Blackbaud Luminate Online® and Blackbaud TeamRaiser®
- 84 JustGiving® from Blackbaud®
- 6.7K Blackbaud Raiser's Edge NXT®
- 3.7K SKY Developer
- 248 ResearchPoint™
- 120 Blackbaud Tuition Management™
- 165 Organizational Best Practices
- 240 Member Lounge (Just for Fun)
- 34 Blackbaud Community Challenges
- 37 PowerUp Challenges
- 3 (Open) PowerUp Challenge: Grid View Batch
- 3 (Closed) PowerUp Challenge: Chat for Blackbaud AI
- 3 (Closed) PowerUp Challenge: Data Health
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Product Update Briefing
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Standard Reports+
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Email Marketing
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Gift Management
- 4 (Closed) Raiser's Edge NXT PowerUp Challenge: Event Management
- 3 (Closed) Raiser's Edge NXT PowerUp Challenge: Home Page
- 4 (Closed) Raiser's Edge NXT PowerUp Challenge: Standard Reports
- 4 (Closed) Raiser's Edge NXT PowerUp Challenge: Query
- 796 Community News
- 3K Jobs Board
- 54 Blackbaud SKY® Reporting Announcements
- 47 Blackbaud CRM Higher Ed Product Advisory Group (HE PAG)
- 19 Blackbaud CRM Product Advisory Group (BBCRM PAG)

