Skip to content

    HTTP Service: Dual Write Data for Ultimate Flexibility

    http service: dual writing for ultimate flexibility

    At Basis Theory we’re making it easier than ever for developers to create products with sensitive data. Our new HTTP service gives developers the flexibility they need to create great products with sensitive data, without having to bring their front-end applications into compliance scope.

    As a merchant or fintech company, having access to your customer PANs gives you lots of options. However, obtaining this data from your current PSP, without breaking contracts or having a PCI compliant place to put them, can be a long and arduous process that is challenging to coordinate among all parties involved.

    We believe there needs to be a better way. Basis Theory's HTTP service allows you to start collecting your customers' PANs in under a day. That's right, you can go from zero to PANs in just 24 hours. And you don't have to worry about breaking contracts or setting up your own PCI environment.

    Let’s dive into the details and see how you can start breaking the stigma of payments being a slow process.

    How it works

    To utilize the HTTP service and collect cards, you'll need to replace your PSP's Elements with Basis Theory's Elements. If you require context, we've covered this process in a previous post titled "How to Replace Stripe Elements with Basis Theory."

    While you have the option to use our elements and the HTTP client to write only to a third-party service, we'll focus on the capability of writing directly to a 3rd party and also tokenizing this data with Basis Theory. This multi-vaulting approach involves effectively sending card data to a PSP while simultaneously tokenizing the values within our Vault.

    stripe-elements-api

    With our service, you can collect your customers' card data one by one as it's gathered from your web application. This grants you ownership of the PANs and reduces reliance on Basis Theory in the operational flow, providing heightened flexibility and control.

    bt-elements-dual-write

    To see this in action, let’s look at an example where we are utilizing this HTTP service with our elements to call Stripe’s API, creating a payment method, and also tokenizing with Basis Theory.

    ...
    const paymentMethod = await bt.post(
    '<https://api.stripe.com/v1/payment_methods>',
    {
    type: 'card',
    billing_details: {
    name: 'peter panda',
    },
    card: {
    number: cardNumberRef.current,
    exp_month: cardDateRef.current?.format('MM'),
    exp_year: cardDateRef.current?.format('yyyy'),
    cvc: cvcRef.current,
    },
    },
    {
    headers: {
    Authorization:
    'Bearer ',
    'Content-Type': 'application/x-www-form-urlencoded',
    },
    }
    );

    const token = await bt.tokens.create({
    type: 'card',
    data: {
    number: cardNumberRef.current,
    expiration_month: cardDateRef.current?.month(),
    expiration_year: cardDateRef.current?.year(),
    cvc: cvcRef.current,
    }
    });
    ...

    Additionally, this HTTP client allows you to call as many third-party endpoints as needed with our Elements. This is great for customers who might wan to fetch card tokens from multiple PSPs.

    Use Cases and Benefits

    You may find many different use cases for this feature that provide benefits to your products and processes. Two main use cases we already see are dual writing credit cards and collecting PII data.

    Dual Writing Credit Cards - The Power of the PANs

    Once you have your card data outside of your PSP this opens up a TON of options for you, none of which you could really do before. We call this the Power of the PANs.

    Here’s a list of how our customers are using this:

    • Continuity Assurance: Stand up as a fallback processor during PSP downtime, safeguarding against disruptions and revenue loss.
    • Improving authentication rates with retries. In case a payment fails and a retry does not work, having access to your card data allows you to try again with another payment service provider (PSP), which could help improve authentication rates.
    • High-Risk Merchant Insurance: With access to your cards, you can direct all payments to another PSP in the event of an untimely shutdown, without costly downtime and being at the mercy of the PSP for a migration.
    • PSP Integration and Testing: With card data on hand, you can easily test out a new PSP’s claims without committing fully to a switch.

    Collecting PII data

    Alternatively, you can use our HTTP client to send inputs directly to a third party without storing the data at all. This is often useful for KYC and other partners that provide a full form experience that differs from the UX of your business. With our HTTP client, your engineers can collect PII from users and send it to their KYC or other partners, while still owning the UX as they would with a normal <input/> form. Using the HTTP client from our elements prevents the end user's sensitive data from hitting your front-end codebase, reducing risk while providing a consistent UI.

    What Will You Build?

    The capabilities of the HTTP service provides flexibility when capturing and sending secure data to 3rd parties. By taking a more agnostic view of how developers accomplish this better aligns Basis Theory’s value with our customers.

    We are always looking for feedback from our users so please let us know the ways you envision this within your organization. We're eager to find opportunities to provide you with solutions that maintain compliance for you while unlocking your ability to innovate.

    Subscribe to the Blog

    Receive the latest updates straight to your inbox