The Wise 3DS API covers 3D Secure authentication — the step-up challenge that sits between a card payment and its authorization. Base URL https://api.wise.com/v2. Its catalog entry carries fifteen properties, including OpenAPI, AsyncAPI, a Sandbox, and nine separate Documentation entries.
3DS is the least glamorous surface in payments and one of the most consequential. Specifying it at all puts Wise in a small group.
Why 3DS is the hard part
A card payment either clears or it does not. 3D Secure is the branch in between: the issuer decides a transaction needs additional verification, the cardholder is challenged, and your integration has to hold state across a redirect, a callback, and a resumption — while the customer waits.
Everything that makes payments integration painful lives in that flow. The transaction is neither approved nor declined. The user has left your page. The callback may arrive before or after the user returns. Liability for fraud shifts depending on whether the challenge completed.
Most providers document 3DS as a narrative walkthrough with a sequence diagram. Wise specified it.
The sandbox property
The Sandbox property is the standout inclusion, and for this API specifically it is close to mandatory.
You cannot test 3D Secure in production. Triggering a genuine step-up challenge requires a real card, a real issuer decision, and a real cardholder — none of which you have while building. Without a sandbox that can deterministically produce a challenge, a frictionless approval, and a failure, you are shipping the branch you tested least.
Naming the sandbox as a first-class property rather than burying it in a getting-started page is a provider acknowledging that this API cannot be adopted without one.
Nine documentation entries and one AsyncAPI
The documentation weight here mirrors the Xero pattern covered this week — a lot of prose carrying a lot of semantics. For 3DS that is defensible: the rules are regulatory (PSD2/SCA in Europe), they vary by region and issuer, and no schema encodes “when is a challenge required.”
The AsyncAPI is the meaningful addition. The 3DS result arrives asynchronously — that is the entire structural problem — so describing the event shape alongside the request shape is what closes the loop. As this week’s AsyncAPI piece noted, only 661 providers on the network describe an event surface at all. In a flow defined by its callback, that description is not optional.
Takeaway
Fifteen properties, a named sandbox, and an event specification on the payment surface that everyone else relegates to a sequence diagram. 3DS is where card integrations actually break, and Wise is one of the few providers treating it as an API worth specifying rather than a footnote in the checkout guide.
See it at docs.wise.com, and the provider entry at apis.io/providers/wise/.