Evervault

Turning on 3D Secure is the easy part. Knowing when it's protecting you and when it's turning customers away is harder. Our guide covers how 3DS works and the metrics that actually matter.

Two healthcare companies booked calls with us last week, but neither of them has checkout pages. One of them handles mail for healthcare businesses -- and some of that mail has card numbers in it. 😱 That's because a lot of US insurers pay doctors by virtual card. The practice gets a one-time 16-digit number (by email, fax or in an actual envelope!), and someone in the billing office keys it into a card terminal the same way they'd charge a patient. The practice pays the card fee, often 3-5% of the payment, which is why doctors' groups have been pushing back on it for over a decade. CMS has said plans can't force providers to accept virtual cards, and New York now requires notice and a fee-free option. The fees get most of the attention, but the card number itself has a pretty strange life. Before it ever reaches a terminal it can be scanned to a PDF, forwarded to a shared inbox and copied into a payment log. Nearly every tool we've built as an industry to protect card numbers is designed around the cardholder typing the number into a payment form. Here the card belongs to an insurer and arrives on paper, and the person entering it works in a billing office and has never met the patient. (The other company that called us has a version of the same problem -- a customer that wants raw card details handed over so it can run them on its own rails.) I'd guess most people in payments have never thought of a mailroom as part of card infrastructure, but in US healthcare it's where a lot of card numbers start their journeys through the financial rails.

A payments platform asked us yesterday to enroll each of its merchants for network tokens individually, rather than all at once under the platform's ID. It's slower and more work (on purpose) -- because it's the only way those merchants can keep their tokens if they ever decide to leave. Network tokens are issued to a token requestor, and they only work for whoever requested them (in theory at least...check out our blog for some of our debunking on this). When a payfac or vertical SaaS platform enrolls everyone under one umbrella ID, every merchant's tokens are technically the platform's. It's simpler to run, and it's what most onboarding calls default to. The problem (usually) shows up years later. A merchant outgrows the platform, or e.g. wants a second processor, and finds out its card-on-file base doesn't come with it. The card numbers can be moved (with some work), but the network tokens have to be provisioned again from scratch, one request to the issuer at a time. Enrolling per merchant flips that entirely. The tokens are tied to the merchant, so they can easily be moved to any provider that accepts external network tokens (which sadly is 𝘯𝘰𝘵 all of them). Most platforms don't realize this was a decision they needed to make at all until a merchant asks to leave. If you run a platform, it's worth being extremely intentional about this. If you're a merchant on another platform, it's worth asking (and triple checking) how they've enrolled your tokens.

We’re excited to be sponsoring Money20/20 Las Vegas this year, and our team will be at stand 3068 throughout the event. Evervault helps payments teams take control of their payment infrastructure by separating card collection and payment capabilities from their processors. This means you can route transactions to any downstream partner, avoid vendor lock-in, and keep your PCI scope to a minimum. Stop by stand 3068 or book a meeting below—we’d love to connect!

OpenAI's new Dots agents can buy things for you, as long as you've already saved a card on that store's website. That's a sensible first version, and it also means the agent only shops where you already shop. The saved-card route is a pretty safe one. The merchant already stores the card, and you approve each purchase before it goes through (OpenAI's help docs spell this out). The errands people actually want to hand off to an agent mostly live somewhere else like a hardware store you've never ordered from, or whichever of six sites has the cable in stock today. Those stores have never seen your card, and almost none of them have (or will have) an API an agent could call. We spoke to a team yesterday building exactly this: an assistant that places orders at any online store, with the person approving each exact cart by text. Their hard problem starts after the approval. The agent has to put a real card into a checkout it has never seen, on a page it doesn't control, running whatever scripts that merchant loaded. The setups which work well (while helping with trust, consent, fraud, etc.) treat the card as a one-time credential. It's bound to the cart the person approved and to that merchant's domains, and it expires in minutes, so the agent never holds the real number and there's nothing useful left behind if the page leaks.

A customer adding Brazilian and Argentine card networks sent us an Elo test card last week, and our BIN lookup called it a Discover credit card. It's a Brazilian debit card, and the lookup wasn't entirely wrong. Discover has held every card number starting with 65 since 2006. Elo, Brazil's domestic network, has ranges inside that block, and so does Nigeria's Verve. Elo also has ranges that start with 4, where most code assumes Visa. The overlap is at least 𝘴𝘰𝘮𝘦𝘸𝘩𝘢𝘵 intentional. Elo joined Discover's network in 2015 so its cards would work outside Brazil, which means a Brazilian paying abroad really is running on Discover's rails. At home the same card is Elo, but the first six digits (alone) can't tell you which of those you're looking at. That matters well beyond the logo on the card form. Brand and funding type decide which acquirer you route to and which fraud rules fire, and a debit card marked as credit throws off your fee and surcharge logic before the payment even starts. We're working on improving our coverage, but the broader point is that brand is a best guess until the processor tells you otherwise -- so trust what comes back from the authorization over what you inferred from the prefix, and keep an override list for the markets you care about. Even the networks' own BIN files get their own cards wrong sometimes.