receptionist_connections_charge_authentication_required
The prepaid first month could not be collected because the card's issuer demands Strong Customer Authentication (3-D Secure and its equivalents): the instrument was not refused and there is nothing to replace, and no off-session request can perform the challenge. Raised by PUT /v1/subscription/receptionist-connections on an increase only, in place of receptionist_connections_charge_declined - deliberately not one code, because a client can branch only on the code and the cures are opposites (replace the instrument versus authenticate on the instrument that works). Nothing changed: the purchased count, both Stripe items and the reserved lane are as they were, and no money moved. The invoice the attempt created is finalized and open, appears in GET /v1/invoices, and its hosted Stripe page is where the customer authenticates; the detail carries hosted_invoice_url inline when Stripe supplied one and points at Billing when it did not. Once that invoice is paid, re-sending the same absolute target on the unchanged instrument replays the same idempotency key and completes the purchase without collecting a second month. Advising a card replacement here is the one thing a client must never do: a new instrument moves the key onto a SECOND invoice. Routine in the EEA, the UK and India.
Problem shape
Every non-2xx response is an RFC 9457 application/problem+json body. The type URI below is stable and machine-matchable, so branch on the final path segment (the code) and treat the status as redundant confirmation. See the error-handling guide.
{
"type": "https://docs.vocapable.com/errors/receptionist_connections_charge_authentication_required",
"title": "…",
"status": 402,
"detail": "…",
"instance": "/v1/…"
}