Report that the device-fingerprint iframe settled, and authenticate
POST/payments/card/authentications/{id}/fingerprint
Both halves happen in one call on purpose: the processor’s 30-second step-up window opens when the issuer answers, so a second round-trip here would spend that budget on our own plumbing.
The response is terminal (authenticated / failed) or challenge_pending
with the step-up handoff.
Authorizations
Section titled “Authorizations”Parameters
Section titled “Parameters”Path Parameters
Section titled “Path Parameters”Our identifier for an authentication.
Example
ca_9Z3K01ARZ3NDEKTSV4RRFFQ69G5FAVAuthentication ID
Request Bodyrequired
Section titled “Request Bodyrequired”What the browser reports once the device-fingerprint iframe settles.
Neither reference nor device_fingerprint is required. The engine
already holds the processor’s collection reference from create and sends
that on authenticate; device_fingerprint is the fallback it sends when
it holds none. An authentication whose device-data-initialize returned no
methodData has nothing to report and can post the card block alone.
object
The cardholder’s billing address. Same posture as customer.
object
ISO 3166-1 alpha-2, e.g. US.
How to reach the cardholder. Forwarded on this call and never
stored. The copy sent on create is the one the processor binds; this
one is accepted because the processor’s own authenticate request also
carries it.
object
The cardholder’s mobile number, as they would write it.
What the browser collected itself. Sent to the processor only when no reference is held — a lapsed iframe budget must not hang the checkout, so the flow continues with this instead.
object
IETF BCP47, e.g. en-US.
Minutes between UTC and local time.
object
A card block for this call — the same one sent on create is fine. The
engine never caches card material, so it is asked for again.
Example
eyJhbGciOiJSU0Et...ENCRYPTED...A processor reference the iframe handed back, if the client read one.
Consulted only when the engine holds none from create; it never
replaces the one it holds.
Responses
Section titled “Responses”Issuer answered: authenticated, failed, or challenge_pending with a challenge handoff to submit within 30 seconds.
An authentication, as the merchant sees it.
Built by hand rather than derived on [CardAuthentication], for the same
reason CheckoutSessionResponse is: the domain type holds things that must
not be echoed. consumed_by, the processor’s own handle, and the merchant
id are all deliberately absent — the merchant references the ca_ id, and
nothing here needs the upstream one.
object
A monetary amount in the currency’s minor units (e.g. cents for USD).
Example
1000Currently supported currencies by Paygasus Pay
Example
USDWhen this authentication stops being usable, in every state — including
authenticated: a verdict that has not been charged by this time
expires and cannot be referenced. Once a charge has used it the field is
informational.
Why it failed, when it did.
Our identifier for an authentication.
Example
ca_9Z3K01ARZ3NDEKTSV4RRFFQ69G5FAVThe lifecycle of one 3DS run.
A plain enum with the state-specific data on [CardAuthentication] rather
than in the variants, matching [crate::checkout_session::CheckoutSessionStatus]
and unlike [crate::payment_intent::CardPaymentIntentStatus]. The reason is
the repository: status is one column and the outcome fields are their own
columns, so [std::str::FromStr] has to round-trip from the string alone.
No such authentication
object
object
When present and true, the caller may retry the same request.
Authentication is not awaiting a fingerprint, or changed while this request was in flight (re-read and retry)
object
object
When present and true, the caller may retry the same request.
Processor unreachable; safe to retry
object
object
When present and true, the caller may retry the same request.