3-D Secure without a phone number: how it works

What 3-D Secure actually is

3-D Secure exchanges transaction and device information between a merchant and card issuer to authenticate an online payment. Many transactions have no visible challenge; others require an additional check such as a one-time code, app approval or biometric authentication. EMVCo describes these methods.

Authentication and payment authorisation are separate. Passing a challenge does not guarantee the payment will complete: the available balance, card status and merchant or issuer checks still apply.

CryptoCard does not offer an account setting to disable a requested challenge. The issuer and merchant flow determine when authentication is needed.

Check the authentication method before choosing a card

A provider can authenticate a card payment without SMS. The useful question is which method the particular card supports, and whether you can access it during checkout.

If an issuer uses text messages, it needs a reachable phone number. Another programme might use an app, biometrics or an email code. Email-only onboarding does not, by itself, prove that a card will succeed or fail at 3-D Secure.

CryptoCard uses the account email for its six-digit code, with pending challenges also shown in the dashboard. Keep access to that inbox and do not share a challenge with anyone else.

How it works here: the code goes to your email

When a merchant requests 3-D Secure on a CryptoCard payment, we send a six-digit code to your account email address. Enter it in the checkout challenge. The payment still needs to pass authorisation checks.

That is the whole reason we insist on an email address and nothing else. It is not a marketing channel and we do not treat it as one: it is the authorisation channel. Which leads to one piece of advice that matters more than any other on this page — use an address you can open on your phone, quickly. A challenge has a short life. An inbox you check twice a week is not one you can pay with.

A few practical notes:

• The code expires on its own. That is what stops an old code being replayed. If it lapses, start the payment again and a fresh challenge is opened.
• Codes are single-use. One challenge, one code.
• Once resolved, the code is gone. It is never shown again, in the dashboard or over the API, which limits what an old inbox leak is worth.

The code has not arrived

Work through these before assuming anything is broken.

• Check spam, then check the address itself. Under Settings → Account, is the address the one you think it is? An address changed months ago and forgotten is a common cause.
• Give it a moment, then restart the checkout. A challenge that expired cannot be revived; a new attempt opens a fresh one.
• Look at the pending challenges. The dashboard lists them, and the code is shown there while the challenge is still open. That path does not depend on email delivery at all.
• Check the service status. If code delivery is degraded, it is published there with a timeline.

One thing that will not help: asking the merchant to resend. The merchant does not send the code and cannot see it.

Reading the code from your own systems

This is the part that has no equivalent on most cards, and it is why a number of people end up here.

Because the code lives on the account rather than in a phone, it is also readable over the API. With the right scope, your own code can list pending challenges, read the confirmation code, and approve or decline the payment — no human in the loop, no inbox to watch.

• 3ds:read — list challenges and read the code while one is pending.
• 3ds:write — approve or decline a pending challenge.

Both scopes are off by default, and that is deliberate. A key carrying them can complete a payment on its own. Turning them on is a decision you take knowingly, for a key that genuinely needs it, in Dashboard → Developers.

The shape of an automated checkout is simple: start the payment, poll GET /3ds?status=pending until a challenge appears, read its code, feed it to the merchant page, and confirm. The resolution is atomic, so two concurrent workers cannot both "win" the same challenge.

When 3-D Secure does not fire at all

Not every payment triggers it, and two paths avoid it almost entirely.

Paying in store through Apple Pay or Google Pay does not use 3-D Secure. The tap is authorised by your face, fingerprint or passcode on the device. If a checkout step is the thing you want to avoid, that is the route — see adding the card to a wallet.

Recurring subscription charges are usually exempt after the first one. The initial payment may be challenged; the renewals normally are not, because the merchant already holds an authorisation from you. That is one reason a card-per-subscription setup works so smoothly — more on that in virtual cards for subscriptions.

Frequently asked questions

Product references and further reading

• CryptoCard fees and funding minimums
• CryptoCard Terms of Service
• EMVCo: authentication methods and the 3-D Secure protocol
• CryptoCard help: payment authentication

Published by CryptoCard. Product terms, eligibility and third-party features can change; use the linked reference for the current details.