日本語
A card testing attack drained $518.91 from one cardholder on July 28, 2026. In detail, it ran 49 automated micro-transactions in one night. The merchant of record was Vercel-hosted. Also, the bank refused to investigate. Meanwhile, the support ticket waited three weeks. By then, the bot had cashed out in three days.
This case shows the full modern card testing attack lifecycle. First, a zero-dollar auth ping to check the card. Then, a tokenization step to bypass 3D Secure. Finally, dozens of micro-charges to drain the limit.
However, the attack itself is only half the story. The other half is how modern SaaS support taxonomies quietly help the fraudster. So this guide breaks down both halves. Also, it gives you the defense playbook Solashi ships to stop it.
Executive Summary: The $518.91 Card Testing Attack Fact Sheet
The case facts are simple.
Date and time: July 28, 2026, 02:22 to 03:49 GMT+7. Attack window: 87 minutes.
Cardholder: a Vietnam-based Visa cardholder. Issuing bank: a major Vietnamese commercial bank. The card was Visa credit with a masked BIN.
Total loss: $518.91 USD, roughly 13,500,000 VND.
Attack pattern: 49 consecutive charges at $10.59 each. Merchant trail on the bank statement: AMAZONPRIME MEMBERSHIP $0.00 (auth ping), Visa Provisioning Service $0.00 (tokenization), and 49x VERCEL at $10.59 (drain). Payment processing ran through a standard Stripe-class gateway (anonymized).
Bank response: refused chargeback investigation. As the reason cited: small-transaction policy for amounts under 700,000 VND (roughly $30).
The Three-Merchant Signature on the Statement
The bank statement told the story in three merchant tags. First, AMAZONPRIME MEMBERSHIP $0.00 posted as the auth ping. Second, Visa Provisioning Service $0.00 posted as the tokenization step. Finally, VERCEL posted 49 times at $10.59 as the drain phase.
This three-merchant sequence is the digital signature of a modern card testing attack. Also, it maps directly to the three steps below.
Basically, the fraudster did not pick these three merchants at random. Each one plays a specific role in the attack chain. In the next section, we break down each role in detail.
The 3-Step Card Testing Attack Anatomy
Basically, a modern card testing attack runs on three steps. Each step masks intent from a different detection layer. Together, they turn a stolen card number into cash in under 90 minutes.
Step 1: The Zero-Dollar Auth Ping Through Amazon Prime
First, the bot tests the card in silence. It runs a $0.00 authorization against a whitelisted merchant. In this case, the tag showed as AMAZONPRIME MEMBERSHIP.
Why Amazon Prime? Basically, most issuer banks whitelist a small set of trusted merchants for zero-dollar auth. Amazon, Netflix, Google, and Apple all sit on that list. So the bank never fires an SMS or push alert on these pings. In practice, the Amazon Prime tag is one of the top covers for card testing.
The trick is subtle. A zero-dollar auth never charges the card. So the bank sends no SMS alert. Meanwhile, the response tells the bot two things. One, whether the card is live. Two, whether the CVV and expiry match.
For the bot, this is a free live-check. For the cardholder, night time silences.
Step 2: Tokenization Through Visa Provisioning Service
Next, the bot tokenizes the card through Visa Provisioning Service. The statement showed this as a $0.00 auth. In detail, this step links the card to a wallet or token on the Visa network rail.
Visa Provisioning Service is a legitimate rail. Merchants and wallets use it every day for Apple Pay, Google Pay, and Click to Pay. However, the same rail also strips 3D Secure from downstream charges. So once the bot completes provisioning, the bank never sends an OTP challenge on later transactions.
In short, a defensive rail becomes an offensive tool. The card now sits inside a trusted token wallet that the fraudster controls.
Step 3: The Micro-Transaction Drain Through Vercel
Finally, the bot runs the drain. In this case, it ran 49 charges at $10.59 each. Each charge posted as VERCEL on the card statement. The gap between charges ran 30 to 60 seconds.
The math is deliberate. Each single charge sits under most bank alert thresholds. Also, each charge sits under Vietnam’s 700,000 VND (~$30) fraud review floor. So no bank system fires an alert.
By the time the cardholder noticed, the total loss was $518.91. The attack ran for 87 minutes.
Why Legacy Banks Miss the Card Testing Attack
The bank’s response is where the story turns systemic. The cardholder filed a dispute. However, the bank refused to investigate.
Its reason: each transaction sat below 700,000 VND. Under bank policy, small transactions do not qualify for manual review.
The economics explain it. Manual chargeback investigation costs the bank $15 to $25 per transaction. A $10.59 charge does not clear that review floor. So the bank pushes the loss to the cardholder.
The blindspot sits in the aggregation logic. Bank policy reviews each transaction alone. It never aggregates across a session. So a $518.91 fraud runs as 49 tiny false negatives, not one clear alert.
Basically, the fraudster’s core innovation is arithmetic. Divide one $500 attack into 49 tiny charges. Every legacy detection layer misses it.
The Support Taxonomy Blindspot: Why Modern SaaS Amplifies Card Testing
Bank blindspots are old news. However, this case exposed a newer problem. The SaaS platform that hosted the merchant had no support pathway for the cardholder.
At Solashi, we call this the Support Taxonomy Blindspot. In detail, three layers of public evidence make the case.
Evidence 1: Severity Taxonomy Excludes the Cardholder
First, Vercel’s own severity taxonomy defines four levels. Each level lists concrete examples of what fits.
Severity 1 covers two cases. One is a production deployment inaccessible to end users. Two is a production deployment subject to a security issue. Both cases assume the person filing the ticket owns the deployment.
Severity 2 covers deployments failing to build. Meanwhile, Severity 3 covers domain verification and integration issues. Severity 4 covers documentation requests.
Notably, none of the four levels lists fraud or unauthorized card use through a hosted merchant. So a cardholder charged $518.91 by a Vercel-hosted merchant fits no slot. Their ticket sits in an unclassified bucket.
Evidence 2: SLA Tiers Gated by Subscription
Second, Vercel’s SLA response times run on subscription tier.
Enterprise Premium Severity 1 tickets get a response in under 2 hours, 24/7. Meanwhile, Enterprise Standard Severity 1 tickets get a response in under 4 business hours. Both tiers require a paid Enterprise plan.
However, Hobby and free tier tickets carry no formal SLA. In practice, response times run 2 to 3 weeks. That is 336 to 504 hours. So the same critical issue gets 250 times slower response on a free plan.
For most SaaS products, this tier logic is reasonable. Docs questions can wait. However, fraud incidents cannot.
Evidence 3: In-Product Upsell Reinforces the Gap
Third, the platform’s own UI compounds the issue. When the victim opened the case, the in-product banner read:
“Awaiting response, someone on the support team will help you soon. For response SLA, consider upgrading to Enterprise.”
In short, the platform pitched an Enterprise upsell at the exact moment a fraud victim needed triage. Basically, this creates a friction paradox. Zero friction for the fraudster running the checkout flow. Maximum friction for the victim reporting the fraud.
The 3-to-5 Day Payout Math
Now the timing math becomes clear. Modern payment gateways send merchant payouts on a 3 to 5 business day cycle. So funds from stolen cards clear to the fraudster’s account within a week.
Meanwhile, the Hobby-tier support ticket sits for 2 to 3 weeks. By the time an engineer reviews it, the merchant has already cashed out and abandoned the account.
This is why card testing attacks target Hobby-tier accounts. They exploit the SLA gap. So the bot cashes out in the head start window that free-tier support quietly provides.
The Solashi Defense Architecture Against Card Testing Attacks
Card testing attacks fail when three defenses run together. Solashi builds all three into every payment build.
Aggregate Velocity Profiling
First, aggregate velocity profiling. So instead of scoring each transaction alone, the system tracks velocity per card, per device, per merchant, and per IP range.
For example, 49 charges of $10.59 to one card in 87 minutes trigger the rule at once. Also, 3 auth pings followed by a tokenization call trigger the rule. The pattern matters more than the size.
In practice, this catches the $518.91 attack pattern in the second or third micro-charge. There is no wait until the 49th!
Layer 6 Upgrade: Ping-and-Drain Detection
Second, Ping-and-Drain detection. This is a specific rule inside our six-layer super app fraud blueprint.
The rule watches for the classic card testing sequence. A zero-dollar auth ping. Then a tokenization call. Finally, rapid micro-charges to the same merchant. When the pattern matches, the system blocks the card and alerts the issuer.
This upgrade fires without waiting for chargeback data. Also, it operates on a rolling window, so it catches attacks that pause between phases.
Decoupled Security Triage as a Design Principle
Third, decoupled security triage. This principle sits above the tech stack. Basically, fraud and unauthorized access reports must bypass standard support queues.
In practice, that means three things. One, a separate intake channel for fraud reports. Two, response SLA tied to incident type, not subscription tier. Three, automatic escalation when the report references a payment card or account access.
For B2B SaaS platforms, this is now table stakes. The alternative is what Vercel’s taxonomy shows. So free-tier fraud victims wait weeks while bots cash out in days.
A Card Testing Attack Escalation Playbook for Victims
If you or someone in your family gets hit by a card testing attack today, here is the escalation playbook. It bypasses the standard support queue that would cost you the recovery window.
First, run public escalation. Tag the platform’s CEO and support account on X with your case ID. In practice, public escalation often cuts wait time from weeks to hours.
Second, use the security channel directly. Most platforms run a security@ or abuse@ address. These inboxes carry higher SLA than billing queues. Also, include full transaction logs and timestamps in the first email.
Third, trigger a card network chargeback. Even if your bank refuses local review, the Visa or Mastercard chargeback process can freeze the merchant’s payout on the payment gateway side. In many cases, this is the only way to stop cash-out mid-cycle.
Finally, file a police report. In many jurisdictions, a formal police case unlocks bank cooperation that policy alone will not.
Card Testing Attack Takeaways for CTOs
Overall, five lessons stand out for CTOs building or scaling payment infrastructure.
First, aggregate velocity beats per-transaction scoring. So design for pattern recognition across the card, device, and merchant dimensions.
Second, treat the auth ping as an active signal. Zero-dollar authorizations are the earliest tell in a card testing attack. Log them and score them.
Third, tokenization is a double-edged rail. It reduces friction for good users. It also strips 3D Secure protection. So add compensating controls on the token issuance side.
Fourth, decouple security triage from subscription tier. Fraud response is core infrastructure. Treating it as a premium add-on invites the exact attack pattern this guide covered.
Finally, design merchant onboarding with card testing in mind. New merchants that show high micro-charge velocity should trigger review rather than silent payout.
Frequently Asked Questions
What is a card testing attack?
Basically, a card testing attack is fraud that runs stolen card numbers against merchants to check whether the card is live. Also, it often chains into a drain phase with micro-charges. So it works as both discovery and cash-out in one flow.
How does a card testing attack bypass 3D Secure?
The attack uses tokenization. First, a zero-dollar auth confirms the card is live. Then, a tokenization call through Visa Provisioning Service links the card to a trusted wallet or token. So future charges skip the 3D Secure challenge by design.
Why do card testing attacks use Amazon Prime as an auth tag?
Because most issuer banks whitelist Amazon, Netflix, Google, and Apple for zero-dollar auth. So the bank fires no SMS or push alert on these pings. In short, the Amazon Prime tag is a stealth cover for the live-check phase.
Why do banks refuse to investigate small card testing charges?
Because manual review costs the bank $15 to $25 per case. A $10.59 charge does not clear that floor. So bank policy sets a lower bound, often around 700,000 VND in Vietnam. Small transactions fall below it.
How can merchants protect against card testing attacks?
Merchants should run aggregate velocity checks per card, device, and IP. Also, they should flag zero-dollar auth pings as an active signal. Finally, they should throttle new merchants that show high micro-charge velocity.
What is the Support Taxonomy Blindspot?
In short, this is when a SaaS platform’s support severity taxonomy has no slot for cardholder fraud reports. So the victim’s ticket has no SLA. Solashi advocates decoupled security triage to close this gap.
Build Card Testing Defense Into Your Payment Architecture
In short, card testing attacks now exploit two seams at once. One is the bank’s per-transaction blindspot. The other is the SaaS platform’s support taxonomy gap. So the defense has to run on both sides.
Solashi ships this defense as standard. Basically, we integrate aggregate velocity profiling, Ping-and-Drain detection, and decoupled security triage into every fintech and super app build. Also, ISO 27001 and ISO 9001 back the process.
Want to see if your payment architecture has the same seams? Book a 30-minute scoping call with Solashi. We will review your fraud stack and your support taxonomy together.
