The proliferation of SaaS, coupled with the ease of subscribing to your favorite things on an ongoing basis has made subscription billing the new standard. Subscription billing requires the storing of payment credentials for current and future use. Because of this, card networks like Visa and Mastercard are adding a new set of regulations designed to identify the initial storage and usage of stored payment information.
Proper usage of the stored credential framework means:
1. Issuers get greater visibility into the transaction risk level
2. Merchants should see higher approval rates and an improved cardholder experience.
This new mandate affects all payment gateways, so it's natural to ask: how is Spreedly responding to these new requirements?
One of Spreedly's goals is to provide a seamless payments experience across gateways, PCI compliant endpoints, and more. Except for rare use cases, you should not see differences when routing transactions to different processors.
We're always evaluating if there's a common interface between payment gateway APIs. Our goal is to allow you to easily take advantage of common feature sets shared between processors with only the change of a gateway token.
Since this regulation is coming from the card networks, the implementation between gateways is usually quite similar. This also means it's a perfect fit for Spreedly's model of abstraction around payment APIs.
At the core of the new regulations, card networks want to know 4 things about each transaction -- and the payment method sent along with it:
1. Is this the first, or subsequent, transaction with this stored payment method?
2. What is the card network transaction id from a previous transaction?
3. Is this transaction with this payment method a recurring transaction?
4. Is this transaction being submitted by the merchant or the cardholder?
With Spreedly as your payment method vault, we already know the answer to the first two questions (without any intervention on your part).
First, we can see how, or if, a payment method has been used before. Since transactions get routed to your payment gateway through Spreedly: we can extract any returned card network transaction ids and inject them into future transaction requests. This gets handled for you by Spreedly - all without you lifting a finger.
So what about questions three and four? That's where you come in.
We've added 2 optional fields to our
endpoints where you tell Spreedly that information: stored_credential_initiator and stored_credential_reason_type
The first describes who is executing the transaction (either the merchant or the actual cardholder) and the reason type describes if it's a recurring transaction, a one off, or part of an installment.
Next we can take what we know about your payment method, what you've told us about the transaction, and then map those values to the appropriate fields in the gateway's transaction request. Also, we're tracking all gateway-specific network transaction ids. So, you can be sure that using your payment method against different gateways will always use a network transaction id returned from that gateway specifically.
Native support for stored credentials is launching with Worldpay. We're working to update more gateways to take advantage of this new mandate.
Interested in seeing your Gateway next on our list? Contact Spreedly Support if you are a current customer. Not yet a customer? Let's connect!
For now, you can learn more in the stored credentials guide in our docs.