Follow-Up on Stripe: Always Forward
Takeaways from my conversations with Stripe's Head of Product for Payment APIs, the Co-Founders of Very Good Security, and Basis Theory's CEO/co-founder.
Last week, in Stripe: Always Forward, I wrote about Stripe’s Vault & Forward API, which they announced at Stripe Sessions, the company’s annual developer conference held in San Francisco two weeks ago. The Forward API allows Stripe merchants to initiate transactions with other payment service providers (PSPs) via Stripe’s API:
The magic of the Forward API is in step #3, where Stripe pulls an Indiana Jones and replaces tokenized data with raw payment details as it relays the request to the third-party PSP.
My main takeaway was that despite the (many) headlines claiming that Stripe was “decoupling” or “unbundling” payments from its software services, interoperability for Stripe is largely an aspiration right now. The main limitation of the Forward API is that it can only initiate transactions with other PSPs. It can’t handle post transaction events like refunds and disputes. But Stripe’s integration with Korean PSP NICEPay—which they also showed off at Stripe Sessions—illustrates how they might work with other PSPs around the world in a much more seamless manner.
Stripe's Head of Product for Payment APIs expands on Stripe’s PSP interoperability
Luckily, Sophie Sakellariadis, Stripe's Head of Product for Payment APIs, Money Movement & Storage, reached out to me confirming a few things I speculated about in my post and sharing some new information about Stripe’s payment APIs. Here’s what she had to say (shared with permission):
Here’s some info on the open questions you mentioned about our Korea integration.
1/ Post transactions events on our NICEPay integration (e.g., refunds, disputes) are, in fact, fully normalized to work how they would for cards.
2/ We were able to normalize that experience because we built NICE on our Reverse API, which requires partners to integrate to a uniform charge, disputes, and refunds spec.
3/ We originally built this API for payment methods like AmazonPay and Revolut. But, as you note, we’ve since found that PSPs dominant in one market want to use it too (including Paystack, as you guessed).
FWIW, on the shortcomings of our Vault and Forward solution, we are working on it! We had so much demand from users to use products like the Payment Element with other PSPs that we decided to ship now rather than wait for the next wave of improvements.
Based on Sophie’s comments, the Forward API is only half the solution to making Stripe interoperable with other PSPs. Stripe also has a Reverse API (still in beta) that allows PSPs to communicate back to Stripe as events like refunds and disputes take place. This allows transactions processed on other PSPs via Stripe to be “fully normalized” in Stripe’s dashboard, API logs, ledger, etc, which is much more convenient for the merchant than using the Forward API and tracking down transactions across multiple PSPs.
The Reverse API was originally built to integrate alternative payment methods (APMs) more quickly. By providing uniform endpoints that eager partners could code to, Stripe “doubled the number of payment methods we provide access to, from 50 to over 100—now including Amazon Pay, Revolut Pay, Zip, TWINT, and Swish” over the past year.
It’s worth noting that APM providers have motivation to roll up their sleeves and integrate into a large and fast-growing PSP like Stripe. In fact, they want to make their payment method available on as many PSPs as possible. I doubt the same is true for other PSPs like Adyen. Sophie also confirmed that Stripe subsidiary Paystack is the Nigerian PSP that will be launching this year with a NICE-like integration, which underscore’s my point about Stripe mainly working with cooperative PSPs right now—often ones that are regionally concentrated and want a more global partner in Stripe. For Stripe to achieve its aspiration of widespread PSP interoperability, I believe they’ll need to find another solution that allows them to plug into other PSPs more quickly. Luckily, there’s another way.
Basis Theory and VGS founders school me on reverse vs. forward proxies
One point that I tried to get across in my last post, Stripe: Always Forward, is that Stripe’s technical implementation for their Forward API has some important limitations. Here’s what I said:
But there are more elegant and flexible technical solutions Stripe could have used to solve this problem. For example, data tokenization companies Very Good Security (VGS) and Basis Theory, offer services that function as forward proxies (vs. Stripe’s reverse proxy), which allow merchants to keep their existing integrations into third-party PSPs and simply replace/redact sensitive data from API requests passing through the proxy based on pre-configured rules. This setup requires more work for VGS and Basis Theory but requires less work for merchants.
To help me expand on this further, I spoke to the founders of the data tokenization providers I mentioned in last week’s post: Mahmoud Abdelkader and Marshall Jones of Very Good Security (VGS) and Colin Luce of Basis Theory. Mahmoud was my co-founder and CTO at Balanced, Marshall was our VP Engineering.
Mahmoud says that a “better way to think of a forward proxy is as a relay.” Meaning a client can make requests to any host it would like without the forward proxy having explicit support for that host. It’s a passthrough, not a destination. Here’s how Marshall put it in a comment on my last piece: “a forward proxy is more like a VPN connection than a HTTP API that you hit so it is more flexible .” The proxy can do nothing and simply allow the request from the client to be sent to the host unchanged. Or, the proxy can modify the payload as it passes through. In the payment context, the modification most often performed is swapping out tokenized data for raw payments data.
Here’s a diagram showing how VGS’s inbound and outbound proxies keep sensitive data out of a customer’s environment:
And here’s an example sandboxed payment request made to UK-based PSP Checkout through a VGS forward proxy:
curl https://api.sandbox.checkout.com/payments -k \
-x USiyQvWcT7wcpy8gvFb1GVmz:2b48a642-615a-4b3c-8db5-e02a88147174@tntsfeqzp4a.sandbox.verygoodproxy.com:8080 \
-H "Content-type: application/json" \
-H "Authorization: sk_test_51*****7e" \
-d '{
"source": {
"type": "card",
"number": "tok_sandbox_w8CBfH8vyYL2xWSmMWe3Ds",
"expiry_month": 8,
"expiry_year": 2025,
"name": "tok_sandbox_w8CBfH8vyYL2xWSmMWe3Ds",
"cvv": "tok_sandbox_w8CBfH8vyYL2xWSmMWe3Ds"
},
"amount": 2000,
"currency": "USD",
"reference": "ORD-5023-4E89"
}'Notice that the host for the request is Checkout—not VGS—and (most of) the request conforms to Checkout’s spec, not one defined by VGS. The only VGS-specific items in the request body that would differ from a normal request made directly to Checkout are the PCI-sensitive fields like number and cvv, which VGS calls “Aliases” and are swapped out for raw card details as the request leaves the proxy. The other VGS-related information specify the proxy vault location, port, and access credentials. The example above uses the cURL shorthand “-x” to define the proxy information in the request metadata. This method is natively interoperable with “pretty much almost everything created on the internet since 1998,” (e.g. cURL, web-browsers, APIs) according to Mahmoud.
Host: https://api.sandbox.checkout.com/payments
Vault location: @tntsfeqzp4a.sandbox.verygoodproxy.com:8080
Access credentials: USiyQvWcT7wcpy8gvFb1GVmz:2b48a642-615a-4b3c-8db5-e02a88147174
Aliases: tok_sandbox_...
So why does the native interoperability of a forward proxy matter to multiprocessor merchants? Because with Stripe’s Forward API, merchants have to code to Stripe’s spec, not Checkout’s for the request to work. This can add additional work for the merchant as they move to a multiprocessor setup and is less flexible because Stripe needs to add support for any new Checkout functionality by supporting the necessary endpoints and parameters in Stripe’s spec first. Colin Luce of Basis Theory says that these “connections don’t change that often,” but it’s worth pointing out because Stripe is going to have its work cut out for it staying current with the APIs of the many underlying PSPs with which Stripe aspires to interoperate.
Colin confirmed that “what Basis Theory and Stripe are doing is technically a reverse proxy.” Which means I got this part of Stripe: Always Forward slightly wrong:
And while, as of today, the Forward API can send data to only six supported third-party processors, the forward proxy approach allows merchants to effectively connect to any third-party PSP “as long as your partner can accept cards through an API endpoint,” according to Basis Theory’s developer documentation.
But while Stripe’s Forward API is currently limited to the six PSPs it supports, Basis Theory has an interesting tool it calls “reactors” to ensure merchants can “connect to any third-party PSP as long as your partner can accept cards through an API endpoint.” Reactors are “serverless functions that can be run in parallel with the proxy,” as Colin put it during our conversation. According to Basis Theory’s documentation, reactors are “similar to AWS Lambda, Azure Functions, or Cloudflare Workers - except your applications, systems, and infrastructure never touches the sensitive plaintext data.” For what it’s worth, VGS has a similar serverless function runtime called Larky. This on-the-fly compute allows Basis Theory to modify both request and response payloads more dynamically than Stripe’s standard reverse proxy, which is how it ensures merchants do not have to wait for Basis Theory to update its API to unblock any underlying PSP functionality.
I’m excited to see how this space plays out and what, if any, technical changes Stripe will make to achieve its interoperability aspirations.
This batch was powered by: