Now that you have created tokens for your external endpoints, like gateways or receivers, you’ll want to test these configurations.
Transaction Requests to Gateways
One benefit of transacting with an integrated partner, like a supported gateway, is that Spreedly hosts several standardized request fields, which can remove some of the complexities of managing multiple gateway integrations. You can use Spreedly’s endpoints for transactions like Authorize, Capture, Purchase (a combined Authorize and Capture), Void, and Refund, to name a few.
Bypassing the payment method token to the endpoint, Spreedly will securely attempt the desired transaction type. Try making a purchase request for yourself.
Transaction Responses from Gateways
Just as we do with your request structure, Spreedly passes standardized response fields from the response that a gateway returns.
For every transaction you complete, you will receive a “transaction token” in the response. This will be used for looking up the specific transaction for that payment method token, so be sure to save that token. You can use this token to search for a given transaction in app.spreedly.com in the “Transactions” tab in the sidebar menu.
The “gateway transaction id”, another field of note, is the reference to that transaction at the gateway. If you want to view that transaction from the gateway’s dashboard, for example, you would use the identifier returned in this field to search for it.
Gateway-Specific Fields and Gateway-Specific Response Fields
As much as possible, Spreedly aims to standardize API requests and responses across supported gateways. Still, each gateway has its own nuances that must be addressed. To account for this, each gateway has its own gateway-specific fields (GSFs) that you can pass when an integration might benefit from a non-standard field; likewise, gateway-specific response fields (GSRFs) are unique fields that are returned from a gateway.
Every gateway will have different fields of these types, so review your gateway guide to see which ones you can use. If your integration requires a field, either in the request or response, that the gateway supports but is not found in our list of fields, you can request this by filling out a Support request form. Please provide a link to the gateway’s documentation for the exact field that you are requesting so that our team can route this accurately.
Spreedly refers to transactions sent to receivers as Deliver requests. Because these requests hit unintegrated endpoints, Spreedly doesn’t enforce the formatting for these requests. You’ll build the request body.
In Deliver requests, you can ask Spreedly to inject elements, like the payment method token, by using the receiver variables. We have a guide on using this functionality, as well as using receiver functions.
Just like gateway transactions, receiver transactions will return a transaction token in the response body. Use this in the “Transactions” tab of app.spreedly.com to search.
If you encounter any issues with your transaction, the best approach is to look at the communication Spreedly had with the gateway or receiver. You can view the full transcript of this exchange by searching the transaction token in the “Transactions” tab of app.spreedly.com as a starting point.
You might encounter errors that occurred via your request to Spreedly or you might encounter errors that the gateway provided after the interaction. A transaction state like “gateway processing failed” is usually an indication that the gateway declined this transaction; therefore, inquiries should be taken directly to the gateway for further clarification. You can refer to what they returned in the “message” field for the gateway’s direct response to the transaction.
Spreedly supports the ability to complete 3DS2 transactions. There are two kinds of 3DS use cases at Spreedly: 3DS2 Global and 3DS2 Gateway Specific.
3DS2 Global is a way to use a single integration across many of the gateways we support. With this solution, you can send 3DS2 authentications directly to a 3DS server. You can use the results of this authentication at any gateway that supports third-party 3DS2 authentications.
3DS2 Gateway Specific involves authenticating against a gateway’s 3DS2 server. This is useful if you are transacting against a gateway and want to use their 3DS2 server for these transaction types; however, a limitation of this solution is that these authentication results can only be used against the gateway you’re authenticating with.
Whichever 3DS2 solution you use, be sure to review the guides closely for best practices.
You have completed Module 4 if you have:
Sent a sandbox gateway or receiver transaction
Sent a sandbox 3DS2 transaction (optional)