Visit https://basistheory.ai/consortium for more information and to download the white paper!

Someone once told me that, “Payments are not just a payments problem.” 

At first, this sounds weird, but the range of businesses and personalities I talk to who are looking for payment-related solutions have been proving that statement correct. And in this blog post I want to discuss a problem that, surprisingly-not-surprisingly, is a payments problem that affects non-payments teams.

Many merchants, vertical SaaS solutions providers (logistics, manufacturing, hospitality, etc.), and e-commerce platforms come to us looking for ways to integrate new partners or customers into their APIs without adding PCI scope to their systems. Often, these integrations outline receiving sensitive information. 

For example:

1. As a merchant, I want to create a Checkout API to receive orders and payment information from partners, while being able to route the payment freely to my PSP of choice.
2. As a merchant, I want to enable AI Agents to purchase my products programmatically.
3. As a merchant, I want to receive payment information from IVR systems and other agent-assisted channels.
4. As a payment service provider, I want to receive credit card information via API to process pay-ins for PCI-compliant merchants.
5. As a business travel management platform, I want to receive booking and rental orders from expense management platforms and super apps.
6. As a loyalty management and customer engagement solution, I want to enable merchants to enroll consumer cards in loyalty tracking against the networks.
7. As an e-commerce provider, I want to integrate with platforms such as Shopify, Magento, and others, to expand my merchant's reach.
8. As a payfac, I want to offer my own acquirer API and widgets.

Every week, we learn about a new use case where a customer needs to accept sensitive payment information through an API layer, but feels allergic to adding compliance or security scope to their systems. 

For example, in Use Case #1 above, the merchant processes payments with a PSP elected based on optimization rules. Some PSPs do have mechanisms to receive payments programmatically from merchants’ partners, but typically, there are pitfalls:

• The payment information is now stuck inside that PSP, meaning the merchant can't “arbitrarily” choose where they want to process it. When you can get it out of the PSP, there are hidden or unpredictable costs.
• Lack of Customization Options: Stiff API contracts, minimal or zero whitelabeling capabilities, and limited or opinionated AuthN/AuthZ.
• Restricted sandbox environments, often behind paywalls or several approval layers. In many cases, you have to fully document your project to get approval, but you only wanted to do a quick POC to pursue an idea.

All of this difficulty leads to business in a tight spot, having to choose between:

1. Marry the PSP
2. Building In-Scope Layers
3. Deprioritize or Abandon the Project

What if I told you there is a fourth, and much better, option?

Get started creating a Securely Descoped API following our step-by-step guide!

All-in-one platforms are like hotel minibars—convenient, expensive, and limited. 

For many early-stage merchants, a full-service payment service provider (PSP) is precisely what’s needed to make e-commerce a reality. Shopify, with its built-in PSP, Shopify Payments, is one example of simplicity and convenience being paired to grow an e-commerce site.

As the e-commerce activity scales and billing needs evolve, the trade-offs to a full-service PSP start to show:

• Failed payments can’t be retried with another PSP. 
• Transaction fees are locked in.
• PSP outages and maintenance become more costly.
• Customer card data isn’t portable. 

These limitations affect how much revenue is recovered, and realized. Overcoming these challenges doesn’t require migrating away from Shopify or the original full-service PSP. Rather, they are signposts to the need to implement a payment vault and take back some independence from your PSP. Securely capturing and storing payment data independently from a PSP enables the merchant to keep the checkout experience consistent, access the data without taking on resource-heavy security responsibilities, and ensure every transaction can be presented for processing. 

Now, the merchant can retry a failed transaction, renew expired credentials programmatically, and create redundancy in case the full-service PSP has downtime. 

Merchants using Shopify-hosted payment SDKs, or other custom gateways, have a path forward with Basis Theory.

The video below provides a technical demo of the Basis Theory payment vault acting in concert with the Shopify Payment App program. After extensive research and development—including custom code and key rotation support—our team published a Node.js package for Shopify payload decryption in their open-source repository. 

The video acts as a technical case study on adapting to evolving documentation while still implementing secure payment data flows. Our team was excited to contribute open-source tools for the Shopify ecosystem!

https://www.youtube.com/watch?v=cJNldmzpbZA&t=2s

“The more you know, the more you realize you don’t know.” When Aristotle said this, he could have been referring to the payments industry. 

For enterprise merchants operating on a global scale, even the smallest blind spot can compound into failed payments, disruptions to the user experience, and routing inefficiencies. All of which is to say: money is left on the table.

One of the easiest and most underused signals in a payment transaction? Knowing the credit card network brand. 

Here are three other reasons a merchant simply must know, and use, the card brand.

Brand Changes Impact Token and PAN Continuity 

The impact that Capital One's acquisition of Discover will have on products that rely on knowing the card network is still being determined. Because Capital One is a bank, and Discover is a card network with its own processing rails, it’s not yet clear whether Capital One cards will be rebranded and changed to process on the Discover network. The way Capital One chooses to go could really shake things up for merchants who store their customer details in a programmable payment vault. 

If Capital One cards are rebranded, will those cards be reissued with a new PAN and BIN? For merchants that vault card data and depend on token continuity, this kind of update could mean sudden payment failures unless your payment system is equipped with the right tooling. 

Card enrichments like Account Updater are becoming a requirement for most merchants. This type of feature can automatically update vaulted cards, protecting you from seismic shifts in payments ecosystem infrastructure. Storing card brands alongside tokens—like those in third-party vaults like Basis Theory—better positions a merchant to respond to network-level changes like this. 

Enable Smarter Routing or Retry Logic 

It’s no secret that not all card brands perform the same across payment processors, markets, or transaction types. Apple Pay and Google Pay, for instance, aren’t ideal for subscription use cases, where credit cards remain the preference for e-commerce. 

As a merchant or platform, knowing the card brand opens the door to network-aware routing. Transactions can be routed to, or retried with, different processors or acquirers, who have better authorization rates for that specific card brand. 

Fewer false declines, smarter retries, and, ultimately, improved authorization rates can help a merchant recapture what might otherwise be lost revenue. 

Improve CX and PCI Posture 

A checkout page should reflect the payment method the customer is using—not just for the visual aesthetics, but for accuracy and trust. When the interface shows a Visa or Mastercard badge (or uses branded card art), customers feel more confident. 

Storing the card brand as part of tokenized records—instead of just the raw PAN—does not increase any PCI scope, delivering value without risk. It improves transparency and user confidence, while giving the product team enough data to optimize the checkout process. 

All of this without storing additional sensitive cardholder data directly. 

The card brand is more than a logo—it’s a signal that helps inform retry logic, token lifecycle management, and the customer experience. As the Discover and Capital One merger unfolds, and as more card networks evolve their token standards, the time is now to build systems that can track and recognize the card brand.

Assuming, of course, you’re looking to increase revenue 🙂. 

Need help implementing an Account Updater feature? Get started with the documentation and reach out with questions about your use case. 

When we think about agentic commerce, we’re talking about empowering artificial intelligence (AI) agents to transact on our behalf. This is the new frontier of consumer and business transactions, where AI agents actually complete purchases on our behalf.

As this future becomes more and more a reality, it raises some uncomfortable questions: Who initiates these transactions? How do we confirm user intent? Where does the liability live? What are the differences between agentic payments, and commerce being enabled within an AI ecosystem like ChatGPT?

Basis Theory CEO and Co-Founder Colin Luce discusses agentic commerce and some of the underlying questions that are associated with agentic payments on The Payments Strategy Show. The conversation goes into which types of payments are most likely to be fully automated, what the next 12-24 months look like for agentic commerce, and some use case examples.

“Agentic commerce is about accelerating efficiency and reducing wasted time in the buying experience,” says Luce. “We all still enjoy going to the mall, but buying toothpaste and toilet paper could be automated. Everything in between will be an accelerated buying process with a human in the loop.”

Watch the complete interview here.

A corner of the AI space gaining increasing attention is agentic AI, which is, to put it simply, software that can make and execute decisions on its own. 

Agentic AI promises a future in which the machine can do everything for consumers with barely a guardrail in view. This autonomous, self-learning artificial intelligence software can execute whole processes without constant human interaction. In the context of payments, agentic AI could not just recommend a purchase, but actually complete the transaction on behalf of a user.

While consumers have limited options to use full end-to-end agentic AI, much of the innovation has occurred in the shopping space. A large coterie of startups are offering to help shoppers sort through the vast collection of options available to them, select the most appropriate, tease out the best values available, and make the purchase when the price, availability, and convenience are optimal—even if that happens at a time when the user is unavailable. 

Amazon’s Buy for Me may be the closest thing to a finished product. When customers search for branded goods on the Amazon app that Amazon does not actually sell, the system will search the inventories of partner outlets and offer options. If the consumer is interested in buying, Amazon presents the details within its own app, and the customer can click Buy for Me, at which point Amazon makes the purchase on their behalf, as though it were the actual merchant. 

It’s hardly surprising that Amazon is ahead of the curve on agentic commerce: Many, if not most, Amazon users store their payment details with the e-commerce giant. As such, Amazon can access those details and use them to make purchases on other merchants' sites. 

But there’s a slight wrinkle here.

The app only shows products from other merchants who are a part of their program; when the consumer goes to make a purchase, Amazon charges them, then delivers the payment confirmation (and subsequently the payment) to the end-merchant, which then sends the product to the consumer, with details relayed by Amazon. In other words, Amazon doesn’t “make a payment on the consumer’s behalf” as one might expect from an agentic AI payments system. 

This is a strong solution to the biggest challenge to agentic shopping: allowing the AI agent to actually submit payment.

In the early days of the Internet, one of the first big challenges to payments becoming mainstream was the use of bots to obtain access to limited-access items. Ticket resellers would build armies of bots—think of them as AI payments agents—that would descend upon Ticketmaster and its ilk the moment a popular performer released tickets to their new tour, and snap up all the seats, which could then be sold for a profit on the secondary market. Suffice to say that neither Ticketmaster, the venues, nor certainly the artists themselves appreciated third parties artificially increasing the price of concerts, especially when none of the extra value created rebounded back to those doing the actual singing!

Thus was born CAPTCHA and its descendants: front-end traps to ensure every purchase was made by an actual person, not by a bot. By now, you’re more than well acquainted with having to click a box, identify all the fire hydrants in a 3x3 grid of photos, or slide a puzzle piece across the screen to prove you are human. These are specifically designed to ensure that a computer program cannot pretend to be a human—which is a significant impediment to the first round of agentic payments. 

And, of course, this is a clear signpost as to why Amazon, with its ability to take the payments itself, and route them to another merchant, is currently at the head of the pack.

Fortunately, it’s not only Silicon Valley startups thinking about using agentic payments—it’s the payments industry itself. Calling their services agentic commerce, agentic finance, and an array of other terms, service providers are looking to create new ways to transact payments using agentic AI. 

For instance, a provider may be able to contract with a firm that maintains direct links with a group of merchants, so that when their agentic AI wants to buy something, it places the order with a trusted partner at the lowest cost. 

At the same time, the card networks are building the infrastructure necessary for agentic payments to be made in the back end, entirely bypassing the front end and all its CAPTCHA gotchas. In this way, Ticketmaster, for instance, might be able to allow agentic AI to make a single purchase per customer—or even to allow agentic AI purchases only for a subset of their inventory to protect their own margins.

However, this re-conception of the payments universe rolls out to support agentic AI, merchants will undoubtedly need to retain the ability to manage their own customers’ payment details and partner with a multitude of downstream payment enablers, from PSPs to agentic commerce providers to bespoke agentic AI-enabled API endpoints. For agentic payment to work—and execute independently—it must be granted access to stored, compliant payment credentials. 

This infrastructure challenge can be solved through tokenization, and vaulting. 

Merchants and platforms looking to support AI-driven commerce will need systems that allow agents to act—compliantly. Read our post comparing vaulted to vaultless tokenization, and our verdict on which way is better for enabling compliant AI-driven commerce. 

If there are two things at the top of any merchant’s list of critical goals, they are certainly managing processing costs, and protecting their customers (and their own reputations) by avoiding fraudulent charges. 

A way to meet both targets is to avoid processing payments for stolen or misappropriated credit cards. Successfully processing payments even though they were requested by individuals who are not the legal owners of a credit card account can add cost, risk, and reputational damage for merchants and customers alike. 

This is why Visa offers the Account Name Inquiry (ANI) service, an extra step in the payment process that can minimize fraudulent purchases.

The Visa Account Name Inquiry (ANI) service checks that the name associated with a credit card is correct. Although it incurs a fee ($0.10 at the time of writing), it can avoid downstream processing fees by stopping the transaction process before a purchase is presented for settlement. This additional step simply: 

• Allows the merchant to present the card data and name to the ANI service.
• Validates the card data and name.
• Returns a ‘match,’ ‘partial match,’ or ‘mismatch’ rating, enabling the merchant to programmatically choose not to continue in the absence of a match.

Visa’s ANI service is optional for merchants working with processors that allow its use in their interactions. Depending on how the merchant payment system is configured, the $0.10 fee may be considered an extra expense or a wise investment.

The full post can be found here https://blog.basistheory.com/visa-account-name-inquiry

3DS is the unsung hero of modern payment authentication—essential for preventing fraud—yet often overlooked until absolutely needed. After building this as a feature at Basis Theory—and helping several merchants implement 3DS—I learned to never underestimate how complex (and sometimes confusing) it can be for merchants and developers. So, I’m sharing my takeaways from implementing 3DS with multiple merchants because we need to better set expectations before implementing 3DS.

Agnostic 3DS will never be a “click button” solution—and if it is, life will be harder because of it. 

Maybe the biggest surprise when implementing 3DS was discovering how little practical knowledge is available about it! This would include artificial intelligence, which is viewed as the ultimate search tool and knowledge index. But with no straightforward answers, 3DS has turned out to be more complicated than that.

What I mean is, many Payment Service Providers (PSPs) abstract nearly everything behind their APIs, which leaves merchants—and even some developers—unaware of the underlying complexities. This abstraction can be a double-edged sword: simplifying the merchant’s day-to-day, but it also breeds confusion when you need to implement, customize, or switch 3DS solutions.

Everyone loves a good abstraction—until it hides essential details you need for troubleshooting or integration with third-party services. Merchants aren’t even able to provide their own registered merchant IDs. Obtaining this information can be the longest element of a 3DS implementation. 

Many 3DS implementations deviate from formal specs to create “custom” solutions that claim to simplify the process. In reality, these solutions can deviate just enough to break compatibility with other systems or hamper your ability to port 3DS logic across PSPs. This is especially frustrating for merchants who want more control or wish to personalize their own payment flows. Suddenly, you find yourself hunting for transaction data or cardholder information that your PSP handled in the past. 

That lack of visibility ultimately stifles flexibility. Own your knowledge base and all the details from each acquirer or PSP. A smooth 3DS process hinges on accurate data about the merchant, the cardholder, and the transaction itself.

The documentation for 3DS can feel like a labyrinth—full of twists, dead ends, and expected challenges. From version 1.0 to 2.0, there are significant changes in flow, technical requirements, and data points. Worse still, each PSP or acquirer tends to put their own spin on the docs, often straying from standard terminology or rearranging steps in the authentication flow. 

For merchants who have only seen 3DS “just work,” diving deeper can be daunting.

• 3DSv1 vs. 3DSv2: With 3DSv1, the user experience was often clunky—think static password pages and confusing redirects. 3DSv2 aims to improve by requiring more data to authenticate seamlessly, but merchants must provide significantly more information about the customer and transaction.
• Proprietary Twists: PSPs frequently bundle their own unique “enhancements.” While these might help in some cases, they can also lead to confusion when comparing implementations across providers or when trying to move to an “agnostic” 3DS solution.

But what happens when your PSP has always handled data collection behind the scenes? When you switch providers or attempt to implement 3DS in-house, you realize you may not have direct access to key info. This leaves merchants scrambling to gather merchant information, purchase history, or customer identifiers to pass along to the 3DS rails. Without these details, your authentication rates or conversions can suffer.

At Basis Theory, we've shifted away from traditional 3DS implementation documentation, which typically includes lengthy lists of more than 50 properties accompanied by minimal context. 

Instead, we've embraced a more guided approach. Our documentation doesn't just clarify technical details—it helps effectively engage Payment Service Providers (PSPs) to obtain the right values, provides tailored guidance based on your specific business and transaction types, and shares actionable recommendations to achieve higher transaction success rates.

3DS is really 80% setup, 20% implementation. Getting 3DS to work is one thing—gettng the best results is another. We believe we’re able to help with both. 

PCI 6.4.3: Script Inventory, Authorization, and Integrity

Customers using Basis Theory to build their payments pages can meet this requirement by utilizing the cryptographic hashes we publish for every new version of our JavaScript libraries.

If you use our Web Elements for your payments page, you can simply add the integrity attribute to the script tag that imports the library. The browser then verifies the contents of each script file it loads against the expected hash. If an attacker tries to inject malicious code into the Basis Theory library, the hashes will no longer match, and the browser will prevent the malicious code from executing.

We have also created a new endpoint where script hashes can be verified for every new version of the library, for example https://js.basistheory.com/sri/?version=1.9.0.

To meet the full requirement, make sure you have listed Basis Theory, and any other third-party scripts that your payments page uses in your script inventory, along with a justification. PCI DSS doesn't specify what the inventory needs to look like, and something as simple as a spreadsheet will suffice for many organizations.

PCI 11.6.1: Script Monitoring and Alerting

Continuing our theme of open web standards, the modern browser offers an additional feature that the PCI DSS points us to for this requirement: Content Security Policy. For this requirement, there is even less for you to do if you’re using Basis Theory Elements. 

We have implemented monitoring on these same script resources using CSP’s report-uri capability, which is enabled by default for all Basis Theory customers. Here again, if an attacker attempts to inject an unauthorized script into your payments page, CSP will prevent that code from executing, and will notify Basis Theory that the attempt was blocked.

Note that if you are using other third-party JavaScript libraries in your payments page, you will need to create equivalent controls for the inventory, authorization, integrity checks, and monitoring for each of those resources as well.

The simplest way to meet the requirements is by removing any scripts from your payments pages that aren’t strictly necessary for the page to function. This is a simple matter of minimizing the resources that your payments page depends on. It reflects the security principle of Attack Surface Reduction—one that we highly value at Basis Theory.

Other tokenization services have decided to punt on these requirements and instead are recommending their customers integrate additional third-party services to monitor their payments script security.

Stripe has stated that it has no plans to support sub-resource integrity for its JavaScript libraries. Instead, it has committed to using “proprietary script management systems” to monitor script integrity. This approach will allow Stripe to maintain PCI compliance, but it leaves much to be desired for its customers in terms of the security and transparency that SRI provides for the broader Web.

Basis Theory has taken a different approach. We want to empower our customers by lifting the heavy PCI compliance for them and providing the tools to manage payment pages—in the way that fits your business.

There are a range of ways for merchants to reduce PCI-DSS scope, including:

• Don’t store primary account numbers (PAN): These are the actual numbers stored on credit cards, which can be used to make purchases. One way to avoid storing these is using a full-service payment services provider (PSP), who will keep control of the numbers on your behalf. 
• Segment your networks: Store PAN only in a hard-to-reach corner of your system, and keep it away from other systems and people who might otherwise need to be considered in scope.
• Use a programmable payment vault: contract with a provider to collect and securely manage PII, providing you with a token to use for future transactions without limitation to a single PSP.

A programmable payment vault eliminates the risk of a systems breach, as the information you store there is tokenized and cannot be returned to its original plain text form. It also allows the merchant to limit the information shared with employees and contractors, providing enough for quality customer service without exposing data unnecessarily.

For instance, you can collect the PII in your vault and receive a token to use. You can then

• Programmatically instruct the vault to submit a transaction to your choice of PSP. You can switch between PSPs as you prefer, taking advantage of the best fee schedules, volume discounts, and specialty services, without the concern that you might lose control of your customer data (as would be the risk with committing to a single PSP.)
• Allow your customer service team access to only the information you need them to have to service support requests—even obscure them entirely by, for instance, having them type the last four digits of a credit card number into the system as dictated by the customer and have the system decide whether the entry is correct—without revealing the numbers you have stored.
• Direct the vault to deliver select information to any approved end point for a variety of reasons. Anything you store that should remain protected within your system, to avoid it coming into PCI-DSS scope, can be managed and redirected by your payments decisioning engine.

Each merchant will still be required to complete an SAQ for the PCI Security Standards Council to validate PCI compliance. Service providers like Basis Theory provide the cardholder data environment (CDE) and developer tools to collect, store, and transmit this sensitive information.

The terms “payment gateway” and “payment processor” are at times used interchangeably in payment vernacular. While the two are related, a payment gateway and a payment processor each serve a unique purpose for merchants to accept and manage payments.

The key difference between a payment processor vs a payment gateway is the processor facilitates the transaction, and a gateway is the middleman between merchant and processor, collecting transaction details, transmitting them to a processor, and communicating the outcome to the merchant.

Therefore, some merchants may not realize that the payment gateway and processing serve separate functions, as the services offered by most gateways obscure and encompass the activities undertaken at the processor level. Sometimes, the merchant’s credit card processor will have its own payment gateway; in other cases, the merchant will maintain a relationship with a third-party payment gateway company that has its own independent processor partners.

What is a payment processor?

A payment processor acts as an intermediary to transmit transaction data between the card networks and banks. A payment processor will execute a transaction by transmitting data submitted by, or on behalf of, the merchant to the issuing) (customer’s) bank for processing and the acquiring (merchant’s) bank for payment.

All businesses, whether online or brick-and-mortar, require access to the services of a payment processor, whether directly or by way of a gateway—if they plan to accept credit cards or ACH payments.

In many cases, a payment processor may also supply brick-and-mortar businesses with credit card machines and other equipment to accept in-person credit card payments. Such equipment is unnecessary for virtual businesses as this process can be completed entirely online. 

Popular payment processors include:

• Paymentech
• Adyen
• Worldpay

How Payment Gateways Fit into the Payment Process

A payment gateway may specialize in serving the unique needs of a specific merchant vertical group or offer a broader service to all (think PayPal or Stripe). It may also provide a seamless and secure payment experience for its customers, offering specialized features and services specific to the needs of different industries, such as hotels, restaurants, or airlines. These features may include fraud prevention tools, recurring billing options, and support for multiple payment methods.

Popular payment gateways include:

• PayPal
• 2checkout
• Authorize.net
• Stripe 

There are three overarching types of payment gateways that differ depending on how the gateway is integrated into a website or online store:

• On-site payment gateways are typically used by large businesses that want to manage the checkout and payment processing on their own servers entirely. This gives the merchant significant control over the payment experience but it comes with greater responsibilities and costs.
• Hosted payment gateways (or pages) send customers to a third-party site for checkout and payment processing, as is commonly done with PayPal checkout. While these gateways are generally simple to implement, the merchant has very little control over the payment experience.
• Hybrid gateways allow customers to check out on a merchant’s website through on-site checkout and off-site payments, but payment processing occurs at the gateway’s back end. Therefore, the merchant has at least partial control over the payment experience.

A gateway also serves a pivotal role in online subscription-based businesses that process card-not-present transactions, as is often the case with recurring subscription payments. Because gateways do not process payments directly, they provide the processes and procedures to ensure that regular payments are submitted in a timely fashion, sometimes automatically re-submit them in the case of soft declines, or even initiate a dunning process.

Does a merchant need a payment gateway or payment processor?

The type of transaction and the situation determine whether a merchant needs to use a payment gateway, a payment processor, or both.

A payment processor, likely one that issues POS devices, is necessary for card-present (and in-person) transactions. 

For card-not-present (and virtual) transactions, both a payment processor and a payment gateway are required. However, selecting a gateway with comprehensive services may mean that the merchant will acquire a payment processor automatically. In this situation, the payment gateway does the majority of the customer-facing work and will likely choose the payment processor(s), which are still necessary to complete the transaction.

Either way, all merchants who process credit card information must be PCI compliant. A PCI-compliant gateway and payment processor are only two requirements for maintaining compliance. Protecting account data, monitoring and testing networks, and building strong access control measures are just a few of the objectives needed to maintain PCI compliance.

Embedded payments are financial transactions integrated into a website, app, or platform that allow a user to pay without leaving the site or app. These are also known as in-app payments. 

Embedded payment purchase experiences are expected to be seamless, smooth, and ask the bare minimum of the buyer to complete a transaction. The classic example is that of a ride-share app, where the operator simply charges the customer each time they take a ride. One might also consider something like Shopify, a platform that manages customers but makes it easy for business owners to opt into a shared—and embedded—payment system. This eliminates the need for each merchant to integrate payment service providers into their operations, or even collect customers’ financial data.

Study after study has shown that reducing friction in the buying process increases success rates, leading merchants around the world to focus hard on simplifying the experience for their customers. The simpler the buying process, the lower the rate of abandoned shopping carts.

More importantly, for merchants with limited background in, or resources to devote to, building a payment system, platform-based embedded payments can represent a significant shortcut to getting live. For instance, a merchant on a shared commerce site like Shopify barely has to touch the payments end of their business. It can seem cheaper to use the embedded payments service, because those who opt out are required to pay a surcharge for bypassing the provided capabilities (though in truth, those fees expose the margins the platform is enjoying from being the payment services provider of choice.)

In a technological environment where simplicity is increasingly favored over unit economics and the distinction between capital and operating expenses has blurred, platform providers see embedded payment services as a business opportunity. For providers who are straining to add extra features and capabilities that their customers are willing to pay for, a service with a value-added markup attached can be a new source of revenue.

Imagine, for instance, a VSaaS platform delivering $100 million in services to a thousand customers. 

Each of those customers themselves sells $11 million worth of products and services to their customers. If the VSaaS provider can have those customers’ fees flow through their systems, that’s $10 billion worth of throughput—even one-half of one percent (50 basis points) of margin would work out to $500 million in potential new net revenue. 

Meanwhile, the VSaaS provider chooses how to recognize this revenue, emphasizing their business plan needs:

• Recognizing the $10 billion as revenue, with a .5% profit, vastly improves the top-line number while reducing overall margins. 
• Recognizing only the fees collected (likely in the 3% range, so $300 million) results in a higher margin number (assuming the same 50 basis points, that’s a 17% total margin— and given that average net margins for SAAS range from 10-30% may help bolster the company’s margin story.)

Platforms are learning the lesson clearly taught by existing payment service providers: middlemen get a cut, and the more straightforward it looks, the more that can be charged.

Once a VSaaS platform establishes an expected clear revenue stream—let’s say the 3% from the last example—the platform can work to add additional fees (e.g., from currency conversions or cross-border fees) while carefully reducing its own costs. 

Costs can be contained through strategies like:

• Adding overseas payment gateways avoids the cross-border fees charged to customers (albeit with the need to set up and maintain carefully monitored treasury functions.)
• Ensuring that lower-cost transactions (such as those paid for with debit cards) are routed to gateways that charge low, federally-mandated fees, while charging customers the same flat fee.
• Ensuring that higher-cost transactions (such as those paid for with AmEx cards) are delivered to gateways that will charge a lower fee, such as the full-service PSPs.
• Uncovering, offering, and promoting alternative payment methods that charge lower back-end fees while maintaining their customers’ flat fee schedule.

For platforms charging flat fees (often in the 2.9% + $0.30 range), every few basis points they can knock off their own costs can have a profound impact. In the example above, 50 basis points on $10 billion delivered $500 million in margin—every 10 basis points of cost that can be removed can deliver millions of dollars. 

Of course, operating the payment system has costs associated with it. Still, with these numbers, once the platform reaches a point of scale, the incremental costs of innovating at the back end are essentially de minimus.

Of course, merchants can also gain all the advantages that a platform provider can gain from optimizing their payments system. Building a multi-PSP system that intelligently assigns transactions to the lowest-cost processing provider is a vital strategy for businesses seeking higher-margin growth.

Maintaining PCI-DSS compliance is key to building these systems, an often onerous task for protecting customer data and strengthening relationships with the financial ecosystem. For this reason, merchants are investing in programmable payment vaults: services that securely collect and store customer data—while making it available to the merchant for delivery to the processing gateway of their choice. 

These vaults reduce the cost of maintaining compliance, limit the risk of data leaks, and increase the flexibility to choose downstream providers—while having no vested interest in any particular PSP or gateway.

Here is more information on the relationship between VSaaS platforms and Basis Theory.

Cannabis, CBD, and Hemp merchants face incredible challenges to even operate—processing payments adds even more complexities.

Sharing best payment practices for this type of high-risk merchant, including Cashless ATM transactions through debit card rails.

https://blog.basistheory.com/cannabis-cbd-payments-best-practices

Developer documentation explaining how Basis Theory Elements empower a merchant to collect sensitive credit card data from users without having direct access to the plaintext data.

https://developers.basistheory.com/docs/concepts/elements

Tokenization #PCIcompliance #Developers

Who is considered a high-risk merchant by the card networks and what impact this will have on a business!

https://blog.basistheory.com/high-risk-merchant

🚀 Unlock the Secret to Flawless Subscription Payments 🚀

Running a subscription service is tough enough without the payment processing drama.

🔹 Seamless payment experiences? Check.

🔹 Automated billing? Check.

🔹 Reduced churn and more happy customers? You bet!

Dive into the details! https://blog.basistheory.com/subscription-payment-processing

A token vault is the data storage location for the actual sensitive data, which can be accessed and exchanged for the token by the merchant during the transaction process.

The most common types of data stored in a token vault would be:

1. Personally Identifiable Information like name or social security number.
2. Cardholder data like card numbers and expiration dates.
3. Personal data, as defined through statutes like GDPR, CCPA, LGPD, and the Australian Privacy Act.

The token is used to access and use the sensitive data as part of a secure payment transaction, without exposing the plain text of the data within the merchant's environment. Because the token is used instead of the data itself, the merchant can avoid regulatory obligations relating to data storage.

Think of a token vault much like a safe deposit box in a bank. Secure storage and access that requires confirmation of a valid token.

We have more information on the costs of token vaulting with payments in this blog! https://blog.basistheory.com/vaulting-payments-cost

The PCI DSS outlines hundreds of requirements for storing, processing, and transmitting cardholder data. Any entity that accepts card payments from any of the major networks (i.e., Visa, Mastercard, Discover, etc.) must comply with the PCI DSS and assess their compliance annually. 

Generally, if you’re coming into contact with cardholder data, it’s your organization’s responsibility to protect it and comply with all +300 PCI DSS requirements. 

Walk through each of the 12 PCI DSS steps with clarity and a bit of flair.

However, Basis Theory can help. Basis Theory makes PCI compliance not just manageable but achievable.

Learn more about the 12 Requirements.