Payments API Changes for CA assembly bill 488

@Mark Groseth, can you share the test account you are trying to test with?

p.s. this functionality won't be live until Jan 2024

@Mark Groseth
It seems there might be a misunderstanding in the Blackbaud (BB) documentation regarding the "transaction_category" property being part of the response instead of the request. To test the Payments API changes for CA Assembly Bill 488 and intentionally trigger error 812, you can try providing incorrect or invalid values for the "transaction_category" parameter in the request object when using the Post Transactions and Post Checkout Transaction endpoints.

Moreover, ensure that the required parameters such as country, state, and zip are included correctly. For further clarification and insights into the API functionality, it's advisable to reach out to Blackbaud support or consult their documentation for any updates or corrections. For more information click here.

Hi @Mark Groseth

Thanks for the question and for being proactive about the upcoming change with CA AB488. We wanted to provide notice so that SKY applications can be prepared in January when this change will take affect.

The actual change will be applied to our Production environment in early January and we'll make another announcement once that date is final. At this current time there is no way to test the change or simulate an 812 response.

Please share a link to where you see documentation about only the response object changing - I am unable to locate it and would like to make sure it's accurate.

Thank you.

@Mark Groseth
Got it. The POST Checkout Transaction endpoint is used to capture a transaction that was already authorized with Blackbaud Checkout. The workflow is:

1. Blackbaud Checkout is launched and transaction_category is passed in as a parameter
2. Blackbaud Checkout applies the transaction_category parameter when authorizing the transaction; a transaction ID is assigned and the modal is closed
3. The Checkout Transaction endpoint is called to capture (finalize) the transaction using the transaction ID. We do not require or allow the transaction_category at this stage because we already gathered it earlier, however we still return it in the response for reference purposes.

Hope that helps clarify the workflow and why it is not required for that endpoint.

Thanks!

@Mark Groseth

The transaction_category and address will be collected at the time of payment when you use the stored payment method to process the recurring gift.