Account — 3D Secure

3D Secure (3DS / SCA) is an extra cardholder-authentication step that reduces fraud and shifts chargeback liability to the card issuer. By default it is mandatory on every Vezmo merchant account. Trusted, high-volume merchants can turn it on or off for their own account — but only after Vezmo admin approval has unlocked the control. Until then, any request to deactivate 3D Secure is rejected with 403.

Regulatory caveat: cards in scope of EU/UK Strong Customer Authentication (SCA) are always authenticated by the card network regardless of this setting. Turning 3D Secure off only affects cards where authentication is optional; it can never bypass a legally mandated challenge.

Required API-key permissions

These endpoints are part of the public merchant API and are API-key-authenticated. Grant the scopes to your key under Settings → Developer Settings:

• account.read — required for GET /merchant/account/3d-secure.
• account.update — required for PUT /merchant/account/3d-secure.

Calls authenticate exactly like the rest of the API: exchange your key + secret for a short-lived access token via POST /merchant/api-auth/login (with the x-api-key / x-api-secret headers), then send that token as Authorization: Bearer <token>.

Get the current setting — GET /v1/merchant/account/3d-secure

Requires the account.read scope.

curl https://api.vezmo.com/api/v1/merchant/account/3d-secure \
  -H "Authorization: Bearer $ACCESS_TOKEN"

Response:

{
  "success": true,
  "message": "3D Secure setting retrieved",
  "data": {
    "mode": "on",            // your choice: "on" (always request 3DS) | "auto" (let the network decide)
    "controlAllowed": false, // whether Vezmo has approved this account to deactivate 3DS
    "level": "automatic",    // configured challenge strength
    "effective": "any"       // what charges actually use — see below
  }
}

Field meanings:

• mode — your selected mode. on requests 3D Secure on every eligible card payment; auto lets the card network decide (only honoured once you are approved).
• controlAllowed — true once Vezmo has granted this account permission to deactivate 3D Secure. While false, attempting to turn it off returns 403.
• level — the configured challenge strength when 3DS is on.
• effective — what charges will actually use: any (request 3DS, frictionless preferred), challenge (force an active challenge), or automatic (let the network decide — the deactivated state, only reached when you are approved and mode is auto).

Turn 3D Secure on or off — PUT /v1/merchant/account/3d-secure

Requires the account.update scope. Send one field — prefer the explicit mode:

• { "mode": "on" } — always request 3D Secure (the default). Always allowed.
• { "mode": "off" } — disable it; let the card network decide (internally auto). Requires admin approval — returns 403 otherwise.

The legacy boolean still works ({ "enabled": true } = ON, { "enabled": false } = OFF); if both are sent, mode wins.

# Turn 3D Secure OFF
curl -X PUT https://api.vezmo.com/api/v1/merchant/account/3d-secure \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{ "mode": "off" }'

Success response (approved account turning 3DS off):

{
  "success": true,
  "message": "3D Secure setting updated",
  "data": {
    "mode": "auto",
    "controlAllowed": true,
    "level": "automatic",
    "effective": "automatic"
  }
}

403 — account not approved to deactivate. If you send { "mode": "off" } while controlAllowed is false:

{
  "statusCode": 403,
  "message": "Your account is not permitted to change 3D Secure — contact Vezmo to enable this control."
}

A body with neither mode nor a boolean enabled returns 400. Re-enabling 3D Secure with { "mode": "on" } is always permitted, even without approval.

Test mode (sandbox)

Use a test API key against the same base URL https://api.vezmo.com — there is no separate sandbox host; the key selects the mode. Note: 3D Secure settings are account-level (shared by both modes). To exercise the deactivate path you need an account that Vezmo has approved (controlAllowed: true); otherwise you can verify the 403 response.