Testing Your External Endpoint Configurations
Now that you've created tokens for your external endpoints, such as gateways or receivers, it’s time to test these configurations.
At the end of this module:
- You will understand how to send a sandbox gateway or receiver transaction.
- You will understand how to incorporate workflow rules using Composer (optional).
- You will understand how to troubleshoot issues or errors.
- You understand the process for importing card data from another secure vault to the Spreedly Vault.
Spreedly offers a low-code/no-code workflow builder called Composer, designed to simplify implementation, orchestration, and payment outcomes.
With Composer, you can leverage normalized request and response fields, minimizing the changes engineering teams need to make in the API. We’ve strategically partnered with a select group of gateways in Composer, allowing you to create interoperable workflows across the gateways in your payment flow.
Gateway Transactions
Transaction Requests to Gateways
One benefit of transacting with an integrated partner, like a supported gateway, is that Spreedly hosts a number of standardized request fields, which can remove some of the complexities of managing multiple gateway integrations. You can use Spreedly’s endpoints for transactions such as Authorize, Capture, Purchase (a combined Authorize and Capture), Void, and Refund, to name a few.
By passing the payment method token to the endpoint via Spreedly, we securely attempt the desired transaction type. Try making a purchase request for yourself. If you have a workflow set up via Composer, make sure to include your workflow key in your Authorize or Purchase.
Transaction Responses from Gateways
Just as we do with your request structure, Spreedly passes standardized response fields from the response returned by the gateway.
For every transaction you complete, you will receive a transaction token in the response. This token will be used to look up the specific transaction for that payment method token, so be sure to save it. You can use this token to search for a given transaction in the Spreedly App under the Performance section in the sidebar menu.
The gateway transaction id, another field of note, references that transaction at the gateway. To view that transaction on the gateway’s dashboard, use the identifier returned in this field.
Gateway-Specific Fields and Gateway-Specific Response Fields
As much as possible, Spreedly aims to standardize API requests and responses across supported gateways. However, each gateway has its own nuances that must be addressed. To accommodate this, each gateway has its own gateway-specific fields (GSFs) that can be passed when an integration benefits from a non-standard field. Likewise, gateway-specific response fields (GSRFs) are unique fields 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 it by filling out a Support Request Form. Please provide a link to the gateway’s documentation for the exact field to ensure accurate routing by our team.
Receiver Transactions
Spreedly refers to transactions sent to receivers as Deliver requests. Since these requests hit unintegrated endpoints, Spreedly doesn’t enforce specific formatting for these requests. You’ll need to build the request body according to the API specifications of the 3rd party endpoint.
In Deliver requests, you can ask Spreedly to inject elements like the payment method token by using the receiver variables. We provide a guide on how to use this functionality and other receiver functions.
Just like gateway transactions, receiver transactions will return a transaction token in the response body. You can use this token to search for the transaction under the Performance section, click on Transactions and use the transaction token to search in your Spreedly App.
Troubleshooting
If you encounter any issues with your transaction, the best approach is to review the communication between Spreedly and the gateway or receiver. You can view the full transcript of this exchange by visiting your Spreedly App. Under the Performance section, click on Transactions and use the transaction token to search. This is a good starting point for troubleshooting.
Errors may occur due to issues with your request to Spreedly or errors returned by the gateway after the interaction. A transaction state such as “gateway processing failed” usually indicates that the gateway declined the transaction. In this case, direct inquiries to the gateway are recommended. You can refer to the message field for the gateway’s direct response to the transaction, and check the response object for additional error codes, if available. Refer to our troubleshooting guide for further assistance.
Migrating Card Data to Spreedly
If you are coming to us from a PCI-compliant storage service, we are happy to help you migrate your card data into Spreedly. Importing your card data is free for every unique gateway or vaulting service you're migrating from.
There are two migration options available:
- One-Time Migration: This is a cut-over to your new Spreedly environment once it’s created and a paid subscription is purchased.
- Gradual Migration: This option allows you to self-manage and meter the migration if a cut-over is not convenient. Please note that API calls for gradual migration will be billable.
To initiate a one-time data migration, please contact Customer Support.
Module Completion
You have completed Module 4 if you have:
- Sent a sandbox gateway or receiver transaction using Composer and the API.
- Created a workflow in Composer with rules for your transactions (optional).
- Used the troubleshooting guide (if necessary) to resolve any issues independently (optional).
- Started the process of importing card data from another vault to the Spreedly Vault (optional).