Our last piece introduced the Payment Card Industry Data Security Standard (PCI DSS) requirements, along with the impacts of working with card data. That content laid the groundwork for this next piece. Your compliance requirements under those standards are heavily impacted by how you collect and work with card data. We’re going to cover some of the main options for ecommerce flows, the pros and cons to each, as well as the impact they have on compliance requirements. If you need to support offline, card-not-present transactions (mail orders, telephone orders, etc.) or other flows, you’ll likely need a separate implementation and compliance strategy.
As in previous chapters, you’ll see callouts like these that we’ll use to provide commentary from a business’s point of view. This fake company is called GetLost, and they’re an online travel agency (OTA). They’re still in the “build phase” and don’t have a live product yet. They’re evaluating their options for collecting and using card data, and they know PCI DSS will apply to them in some way, but they don’t know to what extent yet. They want to understand their options for collecting and using card data, and the compliance implications of those options.
Your biggest consideration is whether you’ll use multiple payment service providers (PSPs). PSPs are companies like Stripe and Adyen that manage most of the payment process. Deciding whether to use multiple PSPs has cascading impacts on other elements, like payments routing, integration complexity, and compliance requirements. Before you make this decision, you should understand why using multiple PSPs is beneficial.
With multiple PSPs, you can:
Most PSPs support card payments through the major networks, but there’s a broad range of local and region-specific payment methods (ACH in the US, Bancontact in Belgium, etc.) that not every PSP offers. Using multiple PSPs allows you to fill these coverage gaps and offer payment methods familiar to customers. This helps with conversion, and when a payment method is supported by multiple PSPs, you can route transactions to the PSP with the lowest fees or the highest acceptance rates. This can save both you and your customers money.
If you use a single PSP and they go down or cease operations, transactions stop. You can’t accept payments and customers may lose trust in your business. If you operate in a high-risk industry or have high fraud rates, PSPs may pause or stop processing transactions for you so that their chargeback rates remain low. In a multi-PSP setup, if any of these events occur, you can instantly reroute transactions to other PSPs so there’s no downtime. This prevents lost revenue and is a much better customer experience.
If you decide to use multiple PSPs, it introduces a second layer of decisions because not every multi-PSP setup is equal. There are different approaches to using multiple PSPs, each with its own pros and cons. You can:
All of the options support multiple PSPs, but they don’t all prevent PSP lock-in, which we’ll cover now.
When you use a PSP to collect card data, it can only be used through that PSP. It’s “locked in”, and you can’t, for example, send that card data to a different PSP to process a payment. Depending on the provider, you might be able to forward card data to downstream partners, but you’re still locked in to your PSP in terms of payment processing. If you did want to use another PSP, you’d need to recollect card data from the customer using that PSP’s system. That’s not a great customer experience, but PSP lock-in also means:
When you collect card information outside of any one PSP, you get more control over payments routing. Support varies (we’ll cover what the different options enable later), but some solutions allow you to do things like BIN lookups to figure out where a card was issued, who issued it, what type of card it is, etc. All of this metadata can be used before payment authorization to effectively route transactions in ways that reduce fees and increase acceptance rates.
You can also configure retry logic to smoothly reroute failed transactions to different PSPs. This is valuable when there’s an outage or if a PSP’s system is down. From a customer’s perspective, they may not even know the initial attempt failed because you can retry the transaction with a different PSP before displaying a receipt or an order confirmation page.
All of these benefits would usually require you to handle card data directly. With a third party like Evervault, you get all of these capabilities while still minimizing your PCI requirements, as solutions like ours ensure raw card data never touches your infrastructure.
We’ll cover each option in detail, but there’s a snapshot below. Because solutions and implementations vary, it’s difficult to provide specific values on the number of controls required, or the precise compliance scope for each option. From an Evervault user perspective, the lowest compliance scope we generally see for merchants is around 27 controls, and for service providers it’s around 60. We’ll still try to give you an idea of the PCI scope, but know that these are generalizations and may not reflect your situation.
| Option | Integration effort | PCI scope | Pros | Cons |
|---|---|---|---|---|
| PSPs | Low to medium | Low to medium | Short or medium launch timeframe depending on implementation | Stuck with PSP’s UX, low customization options, PSP lock-in, can’t use card data outside of PSP |
| Payment orchestrators | Low | Low | Short launch timeframe, no-code payments routing | Stuck with their UX, low customization options, limited use of card data outside the orchestrator, limited to payment methods and PSPs they support |
| Encryption or tokenization platforms | Medium | Low to medium | Full UX control, multi-PSP (avoids PSP lock-in), low risk of breach | Longer launch timeframe |
| Build your own collection and storage systems | Very high | High | Full control over UX, full control over card lifecycle, full control over card infrastructure | Very high cost, hugely resource intensive, long launch timeframe, full PCI compliance, SAQ-D or Level 1 RoC, greater chance of a cardholder data breach (potentially resulting in fines and disabling payment processing) |
As you evaluate these options, think about:
From an internal perspective, you might also want to think about:
The goal is to find the right balance between these elements so you can ship the best experience for your customers, while remaining compliant with the least amount of effort on your end.
From a quick look, we’re probably going to use an orchestrator or a combination of PSPs through an encryption or tokenization platform. We know we need to be multi-PSP from the start, and we also need a solution that lets us integrate with our suppliers and global distribution systems (GDS).
PSPs own card collection and they store your customer’s card data. When you want to charge a customer, you create a transaction with the PSP and they coordinate payment. If you integrate directly with PSPs, you can’t do any routing based on card data. You might be able to do location or IP-based routing, but since you don’t have any pre-authorization card data, you can’t route based on the issuer, or any other card information.
In terms of card collection, solutions generally consist of redirects and checkout forms embedded as iframes into your website. Iframes are not the same as JavaScript forms, which have very different compliance implications. The PCI DSS documentation has specific explanations and guidance related to these solutions if you want to know more.
With redirects, customers click a checkout button or something similar, which then opens a new page hosted by the PSP.
When using a redirect, it changes how and where card data is collected. This reduces compliance requirements because it separates card collection from your systems. Customers enter their card details while on the PSP’s domain instead of yours, and you have little connection to that system.
To implement redirects, your engineering team uses the PSP’s API or SDK to define checkout sessions and initiate the redirect. Interfaces vary, but when a customer clicks your checkout button or similar element, something like this runs behind the scenes.
1 app.post('/create-checkout-session', async (req, res) => {
2 const session = await paymentProvider.createSession({
3 items: [
4 {
5 product_name: 'Coffee mug',
6 price: '1234',
7 quantity: 1,
8 },
9 ],
10 success_url: 'https://yoursite.com/success',
11 cancel_url: 'https://yoursite.com/cancel',
12 });
13
14 res.redirect(session.checkout_url);
15 });In this example, you specify:
When customers finish the checkout process, they’re usually redirected back to your website. Most solutions allow you to specify different pages for successful and failed transactions.
With an embedded solution, you add a piece of code from the PSP to your own site. This is usually an iframe, which is kind of like putting a little screen within your website that shows the PSP’s code. This prevents the domain switch you get with a redirect, and provides a bit more flexibility. From the customer’s perspective, they stay on your site but the form they enter their card details into is contained within the iframe. Iframes can include the entire checkout form or individual fields for the card number, expiry date, etc.
When using iframes, the checkout flow usually has two parts: using an API to create a session, then displaying a checkout form for that session on your frontend. Similar to creating a redirect, you’ll define checkout values for the session using the provider’s API.
1 const session = await paymentProvider.createSession({
2 success_url: 'https://yoursite.com/success',
3 items: [
4 {
5 product_name: 'Coffee mug',
6 price: '1234',
7 quantity: 1,
8 },
9 ],
10 });The part that’s different is displaying the checkout form within your site. PSPs generally have SDKs and tooling for this, which might look something like the example below.
1 async function initialize() {
2 // Fetch session details from your backend
3 const response = await fetch('/create-checkout-session', {
4 method: 'POST',
5 });
6 const { sessionId } = await response.json();
7
8 // Configure the checkout
9 const config = {
10 sessionId: sessionId,
11 onSuccess: (result) => {
12 console.log('Payment successful', result);
13 },
14 onCancel: (result) => {
15 console.log('Payment cancelled', result);
16 },
17 onError: (error) => {
18 console.error('Payment error', error);
19 }
20 };
21
22 // Initialize and mount the checkout
23 const checkout = await PaymentProvider.createCheckout(config);
24 checkout.mount('#checkout');
25 }
26
27 initialize();This uses the session created previously and some additional configuration values to display the checkout form to the customer. There’s of course more to the entire integration (granting purchases, retrying payments, etc.), but this gives you an idea of the work related to the checkout form itself.
The biggest issues are the redirects and lack of customization. Redirects are jarring because customers go from your website, then to the PSP’s to process the payment, and then back to your domain. Some customers may get confused when they’re suddenly moved to another page, which can result in them abandoning transactions all together.
Iframe solutions often provide a better customer experience because you can fit them into your broader site design. Customers also stay within your site during the checkout process, so it’s an overall smoother experience than using redirects.
In terms of customization, many solutions let you set fonts, colors, labels, logos, etc. for the payment form, but there isn’t much you can control after a session is created. Some PSPs support dynamic checkout features, like displaying local payment methods and currencies. These settings are usually configured through the PSP’s dashboard or API, and you’re confined to whatever they allow. For example, you might be not be able to rearrange elements in the checkout form, and there are often limitations on custom fields and metadata (either on the number of fields they allow, character limits, or both).
If you only ever want to use one PSP, or you don’t plan to do complex payments routing, a PSP could be a good fit. If you’re light on resources or time, this option could be difficult depending on the exact integration. Migrating from one PSP to another is painful (you have to migrate card data), so if you ever want to switch or add more PSPs, it’s not always an easy process.
While you can technically go multi-PSP by integrating with PSPs directly, it can negatively impact your customer experience. For example, let’s say you have a primary and secondary provider. If you try a transaction with the primary and it fails, and you want to retry that transaction with the secondary, you have to recollect card information from the customer. Or, if your primary has a drop in acceptance rates and you want to switch to your secondary, all customers that entered card information with the primary will have to reenter their information with the secondary.
The other issue is UI consistency. You’d have to integrate each PSP’s card collection product which means your checkout experiences would be different. Those solutions may not have the same level of customization and functionality, which would lead to an inconsistent experience. To integrate directly with PSPs, it’s better to split out card collection (covered previously), which the next options enable.
This likely wouldn’t work for us. Customer experience is essential and we want to have a consistent UI for every payment. We also want to do things like dynamic retries and custom payment routing to reduce friction and maximize first-time transaction success. To achieve that, it looks like we’d need to decouple card collection from PSPs.
Payment orchestrators own card collection and they store your customer’s card data. They usually have dashboards for configuring payments routing in the form of decision trees or “if this, then that” statements. When customers submit payments, orchestrators use this logic to route transactions to the PSP you want to use. If you decide to use an orchestrator, make sure they have integrations with the PSPs you need. Not all orchestrators support every PSP, and not every PSP supports every payment method. You want to have the right combination so that you can show relevant payment methods to your customers.
Similar to PSPs, card collection is usually done through redirects and checkout forms embedded into your website. You usually build the checkout form using the orchestrator’s UI, and add a few lines of code to your website. This requires little-to-no engineering support to implement.
The same concerns we covered for PSPs relating to redirects and lack of customization apply to orchestrators as well, and you’re confined to what they support. Most orchestrators support different fonts, color schemes, etc. for the payment form, but you can’t fine-tune every aspect. Settings are usually done through a dashboard. Custom fields, metadata, and other optional parameters are often supported but have limitations.
Payment orchestrators do provide a unified checkout experience. Unlike integrating directly with PSPs for card collection, you have a consistent checkout experience across customers and payments because you only use the orchestrator’s tooling for collection.
Payment orchestrators are a good fit for less technical users, and for teams that need basic payments routing. Many of their solutions are UI-based and easy to work with, and they consolidate payments reporting in a single place. You can generally go live quickly, without much, if any, engineering support.
Orchestrators have some limitations. You usually build your payment form with their UI, and you’re limited to the customization options they support. For example, you might be able to configure the colors, fonts, etc., but you might not be able to reorder elements in the form or add custom fields.
For routing payments, you use their UI to build workflows or decision trees. The combination of actions (what to do with a payment) and variables (currency, transaction amount, etc.) are limited. You can, for example, set up logic to send all EUR and GBP payments to a certain PSP, or run 3DS on payments from specific countries. Routing like this can be very beneficial, but it can only go so far. For example, Tebex (one of our customers) is a monetization platform for gamers. They tried using payment orchestrators to route payments at the content creator and game level, but couldn’t get it to work. If an orchestrator doesn’t support a certain action, variable, or your own custom metadata, you’re stuck. You can’t customize workflows outside of what the orchestrator supports.
Similar to PSPs, migrating from one orchestrator to another can be difficult. Because orchestrators store your customer’s card information, you need to work with both orchestrators to extract and move the card data.
The benefits are pretty clear but we need a lot more control over payments routing. We have engineering resources as well, so we don’t have to work under that constraint.
Encryption and tokenization platforms separate card collection from PSPs. They collect card information in similar ways (redirects, iframes, etc.), but the card data is either:
You still use PSPs for payment processing, you just provide the card information to the PSP instead of them collecting and storing it. This separation is what allows you to take advantage of all the benefits we covered before in regard to using multiple PSPs, as well as giving you more control over routing payments.
Most solutions use an iframe or mobile SDK to collect card data within your site or app. With tokenization platforms, you receive tokens that represent card data just like you do with a PSP. The difference is that when you want to charge a customer, you make a call to the platform using the token, they look up the actual card data in their database, and then they share it with your PSP.
With Evervault, the process is slightly different. When customers enter card details, that data is encrypted on the frontend instead of being tokenized.
You store the encrypted card data, and when you want to process a payment, you make a call to your PSP through our secure proxy (Relay). Evervault decrypts the primary account number (PAN) and other card information, and then passes it to your PSP.
This approach is faster (fewer API calls and no database lookups) and more secure (both you and Evervault need to be breached for card data to be compromised).
Unlike with orchestrators, payments routing is done programmatically rather than with a UI. This lets you write any logic you want to determine which PSP to send a transaction to. This requires more effort from your engineering team, but the level can vary depending on how complex your routing is.
While this solution uses an iframe similar to a PSP, the big benefit is that you have a consistent checkout experience across PSPs. You can still customize the form and blend it in with your site’s design and checkout process. There’s also more of an opportunity to monitor the customer experience end-to-end, which can help uncover friction leading to cart abandonment and other issues.
Styling support varies by provider. Most allow general font, color, and layout options. Some, like Evervault, include localization and full CSS customization as well.
If you want more control over the checkout flow and logic, and you want to use multiple PSPs, this is likely a good option. With the right solution, it’s a solid balance between compliance burden, integration complexity, and customer experience. If you have a short timeline to go to market, or if you’re very resource constrained, this option may not be a great fit.
For routing payments, you have a lot of flexibility. You can send card data to almost any third party or PSP that has an API. That of course means you need logic for determining where to route transactions, which can increase the level of effort from your engineering team. The benefit of course is that you can optimize routing based on all sorts of factors, like selecting the PSP with the highest acceptance rates for a particular issuing bank. To do that though, make sure your encryption or tokenization platform can provide detailed card information like Evervault’s Insights APIs. You need that information for more advanced routing logic.
For many years, tokenization has been the primary approach for collecting and using card data. We’ve detailed the problems with this, and Evervault’s encryption approach is:
Because encryption happens on the frontend and you store encrypted card data, you don’t make any calls to Evervault to collect card information. Even if Evervault was down, you could still collect cards. When you initiate payments, you make calls through our secure network proxy to whatever PSP you want. This means our approach is 300-400ms faster than traditional tokenization approaches because:
This improves overall performance and saves you money. With traditional tokenization platforms, every API call to retrieve card data costs you. Evervault essentially removes those costs because there are no API calls to collect, store, or retrieve data. You only pay when you use the data (charge a customer).
Evervault also gives you more ownership over your card data without increasing PCI scope. Because card data is encrypted and stored outside of a PSP or an orchestrator, you can share it with downstream partners (fraud detection platforms, travel booking systems, etc.) through our secure proxy without working directly with the raw card information yourself.
You might hear claims that encryption isn’t PCI DSS compliant because of PCI FAQ 1086. That’s only half the story though, which PCI FAQ 1233 tells the other half of. Encryption done our way is compliant because there’s no single entity that stores the encrypted data and the decryption keys. With Evervault, you store the encrypted data and we manage the keys, so you still get all the descoping and compliance benefits. On top of that, our approach is more secure than using traditional token vaults. If a token vault is breached, card data is out in the open and can be used. For that to happen with Evervault, both your systems and ours would have to be compromised.
Outside of our encryption approach, Evervault supports data transformation that other platforms and their proxy solutions can’t do. We often see situations where our users need to transform or share card data with third parties in bespoke formats (e.g., extracting and sharing the last four digits of a card number). Without Evervault, users would have to store card data themselves, transform or extract the card information, and then share it with their partners. The problem is that this would increase their compliance scope. Instead, our users build workflows like this with functions. This allows them to perform any logic on raw card information without actually storing or touching the data themselves, so their compliance scope remains unchanged. Even if the actual transformation is trivial, the reduction in effort and compliance burden can be huge.
So far, an encryption or tokenization platform is looking like the most likely fit. Our revenue will largely come from bookings, and we need to control payments routing to improve our top line (increase acceptance rates) and bottom line (reduce transaction fees). This option also provides a consistent customer experience and supports multi-PSP. The point about data transformation is interesting. We have to integrate with a ton of suppliers, many of which have legacy or custom-built systems with very specific data requirements.
This option should be the last one you consider. It’s magnitudes more costly in terms of time, resources, initial configuration, maintenance, compliance scope, and risk (security incidents, data breaches etc.). If you’re considering this approach, ask yourself: are there there any business use cases that can’t be fulfilled with a different option? If the answer is no, try one of the other approaches. Even if the answer is yes, it’s worth reviewing those use cases to see how necessary they are.
Integrations can look vastly different and it’s difficult to provide examples because you’re building so much from scratch. The highest levels don’t change in that you have to collect and store CHD, but now you’re doing it all yourself. It includes frontend and backend work, along with security hardening, access controls, cryptography and key management, and a lot more. For whatever you build, you can determine if a system component is in scope for PCI DSS if it:
Regardless of what you build, you can expect months of work across multiple teams, not just engineering. If you’re considering this approach, read our post that estimates some of the costs. It’ll give you more perspective on what you’re taking on.
In terms of customer experience and design, you have full freedom. You’re not constrained by any third party so you can build almost anything you want as long as it’s compliant and secure. More than any other option, you can build something that fits your brand and style.
If there’s no other approach that works, then this may be a good fit. But if there’s any other option that you could get to work for your business, you should try it. It can be tempting to build everything yourself so that you can fine-tune the entire system to your specifications, but the risk of data and security breaches, and the cost of doing so is massive.
This is definitely not for us. We don’t have the resources for it and even if we did, we’d rather devote them to other parts of our product.
As you narrow down your card collection options, it’s worth looking into the compliance requirements a little deeper. It can be a lot to process, so our next piece introduces the requirements at a high level. It also gives you an idea of what compliance looks like at an operational level, and some tools you can use to help with ongoing compliance requirements.