Payment operations Published May 23, 2026 8 min read

3-D Secure for online payments in Armenia: what the website must handle

3-D Secure helps reduce card-not-present fraud, but the website must also handle UX, intermediate states, retries and unfinished authentication.

3-D Secure for online payments in Armenia: what the website must handle

What 3-D Secure does

3-D Secure is an authentication layer for card-not-present payments between merchant, issuer and payment infrastructure.

Merchant -> 3DS -> Issuer authentication
The customer may complete an additional bank authentication step before final authorization.

EMVCo describes EMV 3-D Secure as technology for consumer authentication and improved security in card-not-present payments. For a business this means some payments can require an additional issuer authentication step.

Armenian bank vPOS pages also mention 3D Secure in payment flows. Evocabank describes V-POS for websites and mobile applications with 3D Secure. Checkout should therefore treat 3-D Secure as a normal path, not an exception.

  • payment may move into an additional authentication step;
  • customer may abandon the bank step;
  • final status may arrive later through callback or webhook;
  • mobile browser and in-app flow need separate testing.

How 3-D Secure affects UX

Most problems come from poor return handling, not from authentication itself.

3DS UX failure points
Return URL, mobile app switch, timeout, pending screen and retry message.

When the customer confirms payment in a bank window or app, the site must handle success, refusal, closed tab, timeout, repeated success URL and delayed final status.

The key rule: UX can say the payment is being checked, but it must not fulfill the product or service before server-side confirmation. This is critical for digital products, bookings, CRM invoices and automated delivery.

  • success page shows pending when final status is not ready;
  • fail page offers safe retry without duplicate order;
  • mobile flow is tested in Safari, Chrome and in-app browser;
  • support can see provider reference and last status check.

Which tests are required before launch

Test more than one successful card: include refusal, closed windows and repeated events.

3DS launch test matrix
Success, challenge, decline, timeout, tab closed, retry, webhook delay.

Before launch, the team should test successful payment, bank refusal, unfinished authentication, repeated refresh of success page, closed tab, delayed callback and repeated webhook delivery.

If a scenario is not described, it will still happen in production. The difference is whether the business sees a controlled pending/manual review state or a manual conflict between customer, manager and accounting.

  • check all return URLs and webhook endpoint;
  • ensure raw frontend result does not close the order;
  • store provider reference for support;
  • prepare customer messages for pending and failed cases.

FAQ

Does 3-D Secure guarantee successful payment?

No. It helps authenticate the customer, but payment can still end in refusal, timeout or pending status. Final result must be checked server-side.

Does 3-D Secure need special UX?

Yes. The customer should understand what happens after bank confirmation, what pending means and how to retry safely without duplicate orders.

Can 3-D Secure be disabled for conversion?

That depends on bank, provider, scheme rules and transaction risk. It is safer to design a good 3DS flow than to rely on its absence.

Sources