Cardholder contact details

Where email and phone live, why no card carries its own, and what a 3-D Secure challenge uses them for.

Where they live

A cardholder has at most one email address and at most one phone number. That record is the only place the platform reads them from: nothing else holds a live copy, and no card carries its own.

Your audit trail is the exception, and it matters for a deletion request. Every change to a cardholder's email address or phone number is recorded with the complete cardholder before and after it, so an address or a number you replace — or clear by sending null — survives in the audit entry for that change, alongside the values recorded when the cardholder was created and when they were attested. Webhook deliveries do not carry them: a cardholder.updated event names only the fields that changed, never their values. So updating a cardholder retires a contact detail from every path that uses it, and does not erase it from the record of what it used to be. The same holds for our stored API responses: a create or update request sent with an Idempotency-Key keeps its response — the complete cardholder, email and phone included — so a retry of that key can be answered, and those stored responses do not expire. Count the audit trail and the stored responses in when you answer an erasure request, and tell us if you need one serviced there.

email is optional when you create a cardholder — only programme_id and full_name are required. phone cannot be set at creation at all — add it afterwards with Update a cardholder, in E.164 form: a leading +, then the country code and the number, digits only, 15 at most (+447700900123). A cardholder with no phone number reads phone: null, and one with no email address reads email: null. Both are normal states, not incomplete ones.

Both fields stay editable for the whole life of the cardholder, including after they have been verified or attested — unlike full_name and country, which lock at that point. Omit a field to leave it alone; send null to clear an address or a number you no longer have.

Reading a card back shows cardholder_email next to the card's own fields. That is the cardholder's address, joined on read so it cannot drift out of step, and null when the cardholder has none. It is not a card-level setting, and there is nothing to write there.

There is no per-card override

A card cannot carry its own email address or phone number, and we are not adding one.

The reason is not difficulty. A second place to keep a phone number is a second place for it to go out of date, and keeping them in step would be your job: one number on the cardholder, another on this card, a third on the card you issue next month, all for the same person. Contact details are only worth anything while they are current, and the failure when they aren't is quiet and arrives at the worst moment — the code goes to a number nobody reads, and the payment doesn't complete. One set of details per person is the only shape in which "keep it current" is a single, checkable job.

What a 3-D Secure challenge uses

This section describes Rigid's own ACS: the service that answers a programme's 3-D Secure authentications and decides whether, and how, a purchase is challenged. Some sponsors require their own ACS instead. Where that is the arrangement, the sponsor's ACS makes those decisions under the sponsor's rules, with its own challenge experience and its own cardholder enrolment — which contact details it reads, and whether it offers passkeys at all, are for the sponsor to tell you, and nothing below applies to it.

On Rigid's ACS, most of the time, neither of them.

3-D Secure is a per-programme module (modules.three_ds on Update programme configuration), with its own settings next to it in three_ds_config. A transaction at or below the programme's low_value_exemption_minor_units is answered without a challenge at all — the comparison is inclusive, so an amount exactly on the threshold goes through frictionless.

Where a challenge is needed, a passkey is the preferred way to run it: a confirmation on the device the passkey lives on. Nothing is sent to the cardholder, so neither the email address nor the phone number is read. Enrolment doesn't use them either — a passkey is registered against the cardholder's id and name (Get cardholder passkey registration options, then Register a cardholder passkey), never against their email address. Two things have to hold for that path to run: the programme has a passkey relying party configured (passkey_rp_id and passkey_origins, also in three_ds_config), and this cardholder has registered at least one passkey against it.

Configure the relying party with Update programme configuration, in three_ds_config beside the exemption threshold. Send the two fields together — each origin's host must be the RP ID or a subdomain of it — and reading the programme back shows them. three_ds_config is replaced whole on every update, so an update that sends the threshold without the pair removes a relying party that was set. Until one is configured, registration options fail 400, programme has no passkey relying party configured, and the one-time code below is the only challenge path.

Contact details are what the fallback needs, and until both of those hold the fallback is the only path there is. A cardholder challenged without a usable passkey is sent a one-time code instead: by SMS where they have a phone number on file and SMS delivery is switched on, and by email otherwise. Having no passkey is never itself a decline. It only means the code path runs.

That makes the email address the floor under every challenge a passkey does not carry. It is optional when you create a cardholder, and leaving it out has a cost: without it, the code can only go by SMS. A code that cannot be delivered is not a challenge: if the cardholder has no email address and cannot be sent an SMS, or their contact details cannot be resolved at all, the authentication comes back unavailable rather than approved or declined, and what a merchant does with that is the merchant's rule. A phone number is worth adding wherever you have one, and nothing requires you to.

Two sets of details is two cardholders

Someone who genuinely needs two sets of contact details — a work number on one card, a personal one on another — is two cardholders, each with their own details and their own cards. That is the supported shape.

Know what it costs before you pick it. The cardholder is also the unit a spending account hangs off, and what decides whether one exists is a single module — modules.ledger — not the programme's authorization shape. Where the ledger module is on, each cardholder gets one spending account, provisioned the first time a card is issued to them with the module on and fixed to that card's currency, and every card issued to them after that draws on it — so two cardholders means two accounts to fund, and a balance on one does not back a card on the other. A card issued while the module was off — or just after it was switched on, before card issuance had the change — and before its cardholder had an account, has none and never gains one; re-issue it with the module on. Where the module is off, Rigid provisions no spending account and reserves no money, and a second cardholder costs you nothing on our side.

Keeping your own ledger does not by itself switch that off. A programme runs in Gateway mode when it does not use managed authorization and has a card-auth path configured; that is independent of modules.ledger, so a Gateway programme with the ledger module still on does get an account per cardholder. Nothing is reserved against it — your systems decide a Gateway authorization, which never reaches our funding stage — but the accounts exist, and they are what a second cardholder costs you. Read the module, not the mode.