3DS Challenge Card Testing Method: A Comprehensive Guide
Learn the 3DS challenge card testing method for secure online transactions with CVV purchases.
Redeem your gift cards at any of our Merchants
3DS Card Challenge Test Procedure: Sandbox Steps and Pass Criteria
You can purchase a gift card from any of these locations
Onyx Gift Cards is a Grenadian company designed to introduce, market and manage gift cards systems in Grenada for retailers and corporations. We are enthusiastic about the effect and influence we will have on the local market. We intend to expand our systems regionally with a range of product offerings and services.
Gift cards are the preferred way of giving and receiving gifts. They carry a monetary value that can be redeemed for gifts at your favorite store.
Onyx GiftCards are “Open Gift Cards” which means that they can be redeemed at multiple merchant locations. They are standard credit card size, can fit into the average wallet and made of PVC plastic. Onyx GiftCards are Barcoded for security and safety for the consumer and bear a disclaimer at the back.
Onyx Giftcards can be bought with a branded Card backer which is black in colour and is designed to fit the card. There is an area to write a brief message to the recipient as well.
Short version: the popup your customer sees is only half the story. A 3DS challenge is validated twice. First by the access control server (ACS) when it decides the challenge passed. Then again by the issuer when the authorization arrives carrying the authentication value. If those two halves disagree, the payment fails even though the cardholder typed the right code.
The merchant sends an authentication request with device fingerprint, browser data, and transaction details. The ACS weighs that against the issuer's risk rules. Low risk gets frictionless. Everyone else gets stepped up. The challenge itself is just the cardholder proving control of the account: an OTP, a push in the banking app, a biometric, sometimes a static password.
When the challenge passes, the ACS returns an authentication value, the CAVV on Visa rails or AAV elsewhere, plus an ECI. That value is a signed statement. It says this cardholder authenticated, for roughly this amount, at roughly this time.
The signed value travels with the authorization into the issuer's system. The issuer checks that the cryptogram is valid, that the amount and currency sit inside what was signed, that the timestamp has not drifted too far, that the ECI matches the protocol version in play, and that the merchant is enrolled for that card range.
Any mismatch and the issuer declines, or approves while quietly pushing liability back to the merchant. That second outcome is the one people miss. Failed validation does not always look like a decline. It can look like a clean approval that comes back as a chargeback six weeks later.
Every network publishes test card ranges and a test ACS with forced outcomes. Use the sandbox, force a challenge, then replay the same authentication value against a modified amount and watch what comes back. That single test teaches you more about validation than any spec page.
Log the CAVV, the ECI, the DS transaction ID, and the exact amount and currency you sent in the authentication request. When someone asks why a payment failed, those four fields answer it in about a minute. Without them you are guessing, and the issuer will not guess with you.