3DS Simulation
Where 3-D Secure testing stands in the sandbox today.
No current POST /transactions create path issues a 3DS step-up, and there is no request
field or sandbox value that produces a challenge on demand — the three_d_secure.simulate
field described in older versions of this page never existed. Do not build test fixtures
around an assumed trigger.
Card authentication happens where the card is entered — on the hosted payment page.
The platform's reserved 3DS surface (THREE_DS_PENDING, the issuer-hosted challenge_url, and
POST /transactions/{transactionId}/three-ds/complete) is contracted and documented in the
3-D Secure guide so integrations are correct on the day challenge-issuing flows
ship — build your handlers to tolerate it, per that guide's "building tolerant handlers" section.
What you can test today
- Approvals and declines — driven by the amount's cents portion and CVV values on the hosted page; see Testing and Test cards.
- AVS and CVV outcomes — see AVS & CVV.
- Tolerance of the reserved states — your transaction reads should accept
THREE_DS_PENDINGandTHREE_DS_FAILEDas validstatevalues and handlethree_dsbeingnulleverywhere else. That behavior you can verify with plain unit tests against your own models; no sandbox interaction is required.
Testing guidance for driving a real challenge will ship together with the flows that surface challenges.