
Ticketing
What Declined Transactions Cost a Ticketing Platform
Declined transactions cost ticketing platforms more than fraud does. Here's how to measure the gap and recover part of it.
High volume ticket on-sale payments fail for reasons most teams only find out live. Here's a breakdown of velocity flags, auth throttling, and prep.

During a high demand on-sale, ticketing platforms fail on payments in three predictable places: fraud and velocity rules that read the surge as an attack, issuer-side declines on repeated attempts from the same cards, and processors that respond to abnormal volume by holding funds or imposing a reserve. Preparation means notifying your acquirer in advance, tuning velocity thresholds against your own historical on-sale data rather than steady-state baselines, and having routing redundancy so a single acquirer's throttle does not become your outage.
Ticketing teams treat on-sale day as an infrastructure event, and they are right to. Load testing, autoscaling, virtual waiting rooms, and CDN caching are all standard preparation now, and the industry has learned these lessons the expensive way.
The reference point everyone still cites is the Eras Tour on-sale, where Ticketmaster reported 3.5 billion total system requests, four times its previous peak. The scale problem is well understood.
What gets less attention is that the payments stack is going through the same surge, and it is governed by systems designed to be suspicious of exactly this pattern.
Fraud engines are tuned against your normal week. An on-sale is not your normal week. Thousands of transactions per minute, many from the same geography, several from the same card in quick succession as a buyer retries different seat blocks, all resemble card testing to a rules engine that has never seen your peak.
Even when your side approves, the issuing bank makes its own call. Repeated attempts from one card in a compressed window, an unusually high ticket amount, or a cross-border transaction all reduce the odds of approval. Typical card-not-present authorization rates for US ecommerce run in the 85% to 90% range, and an on-sale pushes you toward the wrong end of that band precisely when volume is highest.
A sudden multiple of your normal daily volume is a risk signal in most underwriting models. The responses range from manual review queues to payout holds to a reserve applied on the spot. Platforms discover this on the day, which is the worst possible time.
Because your fraud engine cannot cleanly separate the bots from the fans, and neither can your issuer.
The scale here is genuinely difficult. In one recent high-profile sale, 96% of traffic came from bots, leaving only 138,000 of 3.3 million requests from legitimate fans.
Mitigation catches most of it. Virtual waiting rooms have blocked more than 13 billion bots across over 17,000 events for one major ticketing operator alone.
Some of that bot traffic reaches checkout. Card testing attempts, where automated scripts run stolen card numbers to find live ones, inflate your fraud reports even when the transactions never settle. That matters more than it used to, because those reports now count against you directly.
Not all automated checkout traffic will be hostile for much longer, and agents buying on a real person's behalf will fail the same "was this a human" check a card testing script does. Our CTO Ben Meeder gets into what that shift requires at the infrastructure layer below.
Significantly, and this is the piece most ticketing operators have not fully absorbed.
Visa's Acquirer Monitoring Program (VAMP) consolidated the old fraud and dispute programs into a single ratio. As of April 1, 2026, the merchant "excessive" threshold dropped from 2.2% to 1.5% across the US, Canada, the EU, and APAC. The ratio combines fraud reports and disputes in one numerator, divided by settled card-not-present transactions.
Two consequences for a ticketing platform.
First, card testing during an on-sale adds to your fraud numerator whether or not the attempt succeeded. A bot wave you successfully repelled can still show up in your ratio.
Second, over-blocking makes it worse rather than better. Declining legitimate transactions shrinks the denominator without touching the numerator, which pushes the ratio in the wrong direction. The instinct to tighten every rule before a big on-sale is exactly backwards.
Treat the payments stack as a named workstream with an owner, the same way you treat infrastructure.
An on-sale is the clearest example of a broader pattern we see across live events: the payments stack is judged on its worst hour, not its average month.
Coinflow is built for the categories where volume arrives in spikes.
Card acquiring is tuned for authorization performance on high-velocity traffic, with multi-acquirer redundancy so a single connection degrading does not stop the sale. Underwriting is done by people who expect a ticketing platform to do a month of volume in 20 minutes, which means abnormal volume is a planned event rather than a risk flag that freezes your funds.
Chargeback indemnification keeps the post-event dispute wave off your ratio and your P&L. And every merchant gets a named solutions engineer who can be on-call during a major on-sale rather than a ticket queue.
Platforms like Novig moved from a single-rail setup to multi-rail acceptance without rebuilding their stack, which is the practical version of redundancy: more ways for a transaction to succeed before it becomes a decline.
If you have a major on-sale on the calendar, talk to our team before it lands, not during.
Yes, and this is more common than most operators expect. Throttling can come from your acquirer protecting its own capacity, from a gateway's rate limits, or from fraud rules queuing transactions for manual review. The practical defense is advance notice to your acquirer plus routing redundancy, so traffic can move to a second path rather than sitting in a queue.
Because the transaction pattern itself lowers issuer confidence. Multiple attempts from the same card in a short window, higher-than-usual ticket values, cross-border cards, and a spike in overall merchant volume all reduce the odds of an approval. Sending richer transaction data, using network tokens, and applying intelligent retry logic on soft declines recovers a meaningful share of these.
Not reflexively. Over-blocking during a surge costs real revenue and, under current Visa monitoring rules, can make your fraud-and-dispute ratio worse rather than better by shrinking the transaction count it is measured against. Handle automated traffic upstream with bot mitigation and a waiting room, then keep checkout rules closer to normal so legitimate buyers get through.
This content is for informational purposes only and does not constitute financial, legal, or investment advice.

Anurag Vuthunuri is Coinflow's Senior Director of Product. He brings experience building and scaling products at fintech companies, including Amount, Uplift, Upgrade, Spring Labs, and Oportun, with expertise across fraud, risk, and product growth.

Ticketing
Declined transactions cost ticketing platforms more than fraud does. Here's how to measure the gap and recover part of it.

Ticketing
Seller payouts take five to seven days on most ticket marketplaces. Here is why, what it costs in listing churn, and how to shorten the cycle.

Ticketing
International seller payouts add vendors, reconciliation, and FX cost. Here's a look at why the two-system model persists and what has the potential to replace it.



