Payment Method Distribution
In addition to the built-in gateway integration, Spreedly also supports the ability to distribute vaulted credit card data to non-gateway, PCI compliant, third parties (referred to as “receivers”). Distribution differs from third party vaulting in that the recipient of the card data is not a known and supported gateway – it can be any third party with whom you do business and is PCI compliant themselves.
How Distribution Works
Using Payment Method Distribution allows you to transact against another service’s API, while still controlling your customer’s card data by vaulting with Spreedly. Consider the following business that needs this ability:
You are a travel service that books accomodations on behalf of your users. You store your customer’s card data in Spreedly up front and use that data to later purchase airline and hotel reservations on behalf of your customers. You only have to ask your customers for their credit card information one time, but can use it to make purchases against several independent services (the airlines, hotels etc…) at booking time. The card data is only transmitted between PCI compliant parties (Spreedly and the airline and hotel endpoints), ensuring compliance with PCI standards.
Spreedly’s payment method distribution functionality enables businesses to transact with multiple PCI-compliant endpoints on behalf of its customers, via a single, consistent, integration.
Single vs. Batch Distribution
Payment method distribution can operate in two modes - single card vs. batch export. If you have an external HTTP API you wish to target that exposes an endpoint that accepts a single card per call, you need the single card mode of PMD. If you have an SFTP endpoint that accepts a file containing multiple cards, then use the batch export mode of PMD.
In both modes, the basic workflow remains the same. You specify a template that tells Spreedly how to format the request, the card or cards to deliver, and Spreedly executes the call on your behalf. Batch export operates in an asynchronous fashion, which involves a little more complexity, but the two modes have more in common than they do otherwise.
Supporting Your Receiver
You can begin developing and testing your PMD workflow using a test receiver. However, before you can distribute real payment method data, you have to get your receiver confirmed and white-listed. Please email the following information to Spreedly to get your receiver in the approval queue. (Alternatively, if you have an existing relationship or contact at the receiver company, you can direct them to Becoming a Receiver. This page is written from their perspective and lets you avoid just being a go-between Spreedly and the receiver.)
- The receiver name/company along with a link to their public site
- Proof of the receiver’s level of PCI compliance. Their AOC and most recent security scan usually suffices. Please make sure there is an explicit correlation between the company with the AOC and the API endpoint URL. You can see an example of an AOC and security scan with Spreedly’s own documents which are publicly available.
- The production URL you will be invoking on the receiver with Spreedly payment data. The production URL must utilize SSL.
- While the endpoint must utilize SSL, Spreedly does not require the SSL certificate to set up and whitelist the domain. Therefore, you are not affected when the receiver updates certificates on their end. If there will be a domain change, please contact Support and let us know in advance.
We ask that you allow several weeks for Spreedly to approve and configure a receiver for production use. During this time you can begin testing against a test receiver, which allows test payment methods to be delivered to any user-specified endpoint URL.
Once you’ve set up your receiver, you can see which requests are powered by Spreedly by looking for the
X-Transaction-Powered-By: Spreedly header. Filtering requests to ones with this header can be helpful for debugging and for tracking Spreedly-originating transactions.
List of Supported Receivers
We currently support the following receiver types (and their associated whitelisted URLs):
|Company||Receiver Type and Hostnames|
|Ace Rent a Car||
|Alliance Reservations Network||
|Allianz Global Assistance||
|Blue Ribbon Bags||
|Cybersource Decision Manager||
|Diane Von Furstenberg||
|Expedia Affiliate Network||
|Economy Rent a Car||
|Electronic Payment Exchange||
|First Data India Pvt Ltd.||
|Global Technology Partners||
|iFly Res (IBS)||
|Mastercard Member Test Facility||
|Network for Good||
|NÜ Car Rentals||
|Pace Payment Systems||
|Transcor Data Services||
|Virtual Card Services||