3-D Secure

Every card payment on Inkress is verified with 3-D Secure. This page explains what that means for your integration.

Required

3-D Secure runs on every card payment

It is not a per-merchant setting, not a per-transaction option, and it cannot be turned off. If your integration was built when 3-D Secure was occasional, the most important change is this: a card payment is never complete at the moment the customer submits the form. The customer's bank has to verify them first.

What 3-D Secure does

3-D Secure is the step where the cardholder's own bank confirms it is really them. Depending on the bank, the customer might approve the payment in their banking app, enter a one-time code, or complete a challenge on their bank's page.

It protects the cardholder

Someone holding a stolen card number cannot pass the cardholder's own bank verification.

It protects the merchant

A verified payment shifts chargeback liability for fraud claims away from the merchant, which materially reduces dispute exposure.

It is a hard gate on the money

If the bank's verification does not come back strong enough, the payment does not go through — even when the card itself is perfectly valid.

What the customer sees

1

Card entry

The customer enters their card details in a secure frame hosted by Inkress. The Pay button stays disabled until those details are valid.

2

Processing

A modal opens over the checkout. The customer stays on your page.

3

Bank verification

The 3-D Secure challenge appears inside that modal — an app approval, a one-time code, or the bank's own page.

4

Result

The customer is taken to the payment status page, which confirms success or explains the failure.

Card details are entered in the secure frame and exchanged for a token. They never reach your servers and Inkress does not store the card number.

What this means for your integration

Never treat submission as payment

The gap between “the customer pressed Pay” and “the money moved” now includes a round trip to the cardholder's bank, and the customer can abandon it. Fulfil on the confirmed payment, not on the submit.

Fulfil on the webhook, not the redirect
// Wrong — the customer may still be mid-challenge, or may abandon it
app.post("/checkout", async (req, res) => {
  await inkress.charge(req.body);
  await fulfilOrder(req.body.orderId); // ← too early
});

// Right — fulfil when Inkress confirms the payment
app.post("/webhooks/inkress", async (req, res) => {
  const { event, order } = req.body;

  if (event === "orders.paid") {
    await fulfilOrder(order.id);
  }

  res.sendStatus(200);
});

See Webhook Events for the full list, and Webhook Security for verifying that a delivery genuinely came from Inkress.

Allow a generous timeout

A 3-D Secure round trip depends on the customer reading a message, opening an app, and typing a code. Client timeouts that were fine for a direct authorisation are far too short now. Give the charge call room — tens of seconds, not a handful — and show the customer a waiting state rather than an error.

Design for the failure cases

These are ordinary outcomes, not exceptions. Your checkout should handle each of them without dead-ending the customer.

Customer abandons the challenge

They closed the modal or never finished. The order is not paid. Let them retry.

Bank declines the verification

The bank was not satisfied. The customer needs to contact their bank or use another card.

Customer never receives the code

Their bank sends it, not Inkress and not you. Neither of you can resend it.

Verification is not strong enough

The bank responded, but not with a result strong enough to take money against. The payment is declined.

Decline responses carry a human-readable reason. Surface it to the customer as-is rather than replacing it with a generic “payment failed” — it usually tells them what to do next.

Recurring payments

Subscriptions work differently, and deliberately so. The customer completes 3-D Secure once when they set the subscription up. Later renewals are charged against the stored credential without asking the customer to verify again — otherwise every renewal would fail whenever the customer was asleep or away from their phone.

When a stored card stops working, the fix is the self-serve card update flow, which runs a fresh verified authorisation. See Subscriptions.

Common questions

Can I disable 3-D Secure for my account?

No. It applies to every card payment on the platform.

Can I disable it just for trusted customers?

No. There is no per-customer or per-transaction bypass.

My conversion dropped after this change.

Some drop-off at the bank verification step is expected. It is offset by a large reduction in fraud-related chargebacks, which are far more costly than a retried checkout.

Can I test without a real bank challenge?

Use the test credentials issued with your integration. Contact support if you need a specific challenge scenario reproduced.

The customer says they were charged but the order is not paid.

An authorisation hold can appear on a statement before it is released. Check the order's transaction detail before treating it as a double charge.