Card Testing and URL Links: A Comprehensive Guide
Explore the essentials of card testing and understanding URL links in the context of want-to-buy CVV transactions.
Redeem your gift cards at any of our Merchants
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.
A payment link card test runs a checkout page with a sandbox card number instead of a real card. Processors such as Stripe, Adyen, Square, and Braintree publish fixed test numbers that trigger an approval, a decline, or a 3D Secure challenge on demand. No money moves, and no real card data enters your system.
A payment link is a hosted checkout page with a set price and no shopping cart. During a test, a sandbox number replaces the shopper's card, and the processor routes the request to its test environment. Your server sees the same webhook events that a live payment would send.
A payment link skips your own front end. That narrows the test to three parts: the link setup, the processor, and your webhook handler. When a real order fails, those three parts are the first places to check.
Links also cover paths your checkout page cannot reach. A link inside an email, a QR code on a printed invoice, or a page opened in the Instagram in-app browser all run through the same hosted flow.
Run the flow again with a decline number, an expired number, and a number that fails the CVC check. Each run should show a different message to the shopper and a different event to your server.
Each processor publishes its own list, and the numbers do not match between providers. Stripe documents 4242 4242 4242 4242 as a generic success card and 4000 0000 0000 0002 as a generic decline. Adyen, PayPal, and Square list their own sets in their developer docs.
Use the list from the processor that runs your links. A number that passes on one gateway can fail on another, so copy the number from the docs of the provider you use.
The most common mistake is testing with a real card number, including your own. A live number creates a real authorization, and the refund takes days to settle. Test numbers cover the same paths with no money at risk.
Logging is the second trap. Storing a full card number or a security code puts you outside PCI DSS rules, even in a sandbox. PCI DSS forbids keeping the CVC after authorization, so scrub it from your logs and your database.
A third problem is a shared webhook endpoint. If test links and live links post to the same URL, test events land in the same queue as real orders. Split the endpoints or filter events on the livemode flag.
A card validation check asks whether a card is open, often with a zero-dollar or one-dollar authorization. A payment link test asks a wider question: does your checkout flow, webhook handler, and receipt path behave as expected. The two checks use different tools and answer different questions.
You can, and some teams do this before a launch. It works for a small amount, but the refund takes days and the test is hard to repeat. Test numbers cover the same paths with no money at risk.
Yes. Most processors let a test number force an authentication challenge, an authentication failure, or an attempt that the bank skips. Test all three, since each one returns the shopper to a different page.
Re-run it after any change to your webhook handler, your return URL, or your prices. The link itself is static, but the code around it changes with every deploy.
They do, in test mode. Check the Apple Pay and Google Pay sheets in a sandbox build, since those flows skip the card form and can hide a broken return URL.