The payments leader’s playbook for peak season 2026

Peak season 2026 is around the corner, and for merchants, Black Friday and Cyber Monday will put payments performance under some of the most intense pressure of the year.

Adobe expects US consumers to spend $275.1 billion online between November and December this year, with $47.5 billion of that concentrated into Cyber Week. Black Friday alone is forecast to generate $12.9 billion in online sales, followed by a record $15.1 billion on Cyber Monday. 

For your payments team, that means far more transactions hitting your stack in a very short period of time. 

Primer data shows just how sharply peak can change payment activity. During Black Friday week last year, one large European retailer saw total payment volume (TPV) rise more than 100% week over week and reach three times the level seen a month earlier, while payments created also increased over 100%.

Once volumes start moving, your team will have little time to react. At that scale, even a small drop in payments performance puts far more revenue at risk.

Peak season also changes who is buying and how they pay. You'll see more new shoppers, more cross-border purchases, and shifts in payment method preference. 

Understanding what's driving those changes often means pulling together signals from across your payments system, and this is where fragmented payments data starts to cost you. For instance, you might see that your authorization rate has moved, but you can't always see why quickly enough to do something about it.

To understand where payments teams should focus in the weeks leading up to peak season, we spoke to Christopher Bucceri, VP and Senior Relationship Manager at J.P. Morgan, and our Product Operations Manager, Mohamed Aziz. Their advice covers what you can still pressure-test now and how to make better decisions once the volume arrives. 

Find the edges of your payment setup before peak does

With only a few weeks to go, one of the most useful things you can do is find out where your existing setup starts to behave differently under load.

Bucceri recommends testing “well above” the peak you expect to see. 

“Don’t test for ‘average peak.’ Test well above it. If you think you could get to 1000-3000 transactions per second, test at 1000, 3000, and 5000. Measure how latency changes at each level so you know what to expect as transaction volume increases.” 

What you’re looking for is the point where your system starts to behave differently. Latency can creep up with higher volumes, and an API or merchant account may hit a rate limit. If it does, you need to know whether your provider will queue those transactions or fail them.

Higher volume also amplifies weaknesses that are already there. Bucceri regularly sees merchants sending incorrect customer-initiated and merchant-initiated transaction (CIT/MIT) indicators, wrong recurring or stored credential flags, or incomplete billing and shipping information. Even if those issues exist all year, they're worth fixing before every basis point carries more weight.

The same goes for fraud controls. Rules built around normal transaction velocity can behave differently when legitimate traffic surges, and spikes in genuine customer activity make card testing and bank identification number (BIN) attacks harder to spot.

The point is to find the limits of your setup while you still have time to do something about them.

Know what “normal” looks like before peak changes it

Once peak traffic starts moving, a change in your authorization rate doesn't automatically mean something in your payments stack has gone wrong.

"A 4% decline rate means nothing without a baseline," says Aziz.

That baseline gives you something to compare against when the shape of your traffic starts changing. Bucceri suggests separating two kinds of movement.

“Look for ‘mix-driven’ changes such as more new customers or cross-border transactions on certain SKUs, versus ‘stack-driven’ drops such as latency or timeouts.”

Working out which one you’re dealing with means looking beyond your authorization rate to see where the change is actually coming from. You need to see where the movement is concentrated, whether that’s a particular processor, issuer, BIN, country, payment method, or decline reason. Aziz notes that a shift in decline reasons can often tell you more than the overall decline rate itself. 

Things get more complicated if you work with multiple processors. The same underlying issue can show up under different decline codes, while retries, fallbacks, and 3D Secure (3DS) add more steps to piece together when something fails. Normalizing that data lets you see the pattern across your whole stack rather than investigating each provider separately.

“One declined card tells you nothing. Five hundred declines from one issuer in 20 minutes tells you where to look,” adds Aziz. 

During peak, the real advantage comes from being able to isolate what changed before you decide how to respond. 

Build the response before you need it

Once you know what to watch, the next question is what happens when one of those signals moves.

Bucceri says the best-prepared merchants go into peak with a playbook they already know how to execute.

“Your playbook should work like a decision tree. If X happens, we do Y. If A happens, we wait to see whether B follows. If it doesn’t, we leave it alone. If it does, we move to C immediately.”

That means agreeing in advance on the thresholds that warrant action, along with who owns the response and when to pull in a provider.

Aziz recommends setting alerts relative to your usual baseline rather than relying only on fixed thresholds, and making sure that baseline reflects peak conditions. Comparing Black Friday to an ordinary Friday will flag drops that are just a shift in traffic mix. Comparing against last year’s peak, or baselining per processor, issuer, and country, means an alert fires when one segment moves out of line, not when the overall mix changes.

He also suggests watching for signs that a processor is starting to struggle before declines increase. 

“Watch API error rates, processor response latency, timeouts, and webhook delivery failures. Latency creeping up is often the earliest warning that a processor is degrading, before declines spike," he explains.

Spotting the problem only helps if your team knows what happens next. Aziz advises sending alerts to a shared channel, with a named owner and a runbook that sets out the first response.

“An alert that doesn't say who acts and what the first step is just becomes noise.”

Test those alerts before peak too. Aziz also says it's important to agree on escalation paths in advance and document the routing, fallback, fraud, and 3DS configuration before any change freeze begins. 

The less your team has to debate in the middle of an incident, the faster it can act on what the data is saying.

Be deliberate about what you change so close to peak 

The final weeks before peak can create a push to squeeze out a little more performance. Every change also introduces something new for your team to operate when volumes are at their highest.

Bucceri believes some things are better left untouched.

“I would not implement a new payment method anytime near peak volume, unless you feel 100% confident that your teams can handle it,” he warns. “Issues with reconciliation, chargebacks, refunds, and customer support will likely be spiking, so you don’t also want an influx in questions about this new payment method that is starting to cause issues.”

The same judgment applies to recovering declined payments. Bucceri sees a real opportunity in retrying eligible soft declines, but cautions against simply adding more attempts. Hard declines should rarely be retried, and excessive retries can run into card network limits and affect how issuers assess later transactions.

At this stage, you need to be confident your team can handle everything a change introduces once peak is underway.

Peak doesn’t end at authorization

Most peak-season planning is about the build-up. Teams spend weeks getting ready for the moment volume hits, and far less time thinking about what happens once those payments go through. Every successful transaction still has to settle, reconcile, and sometimes be refunded, and that work keeps growing long after Cyber Monday ends.

This is one area Bucceri sees merchants address too late.

"With greater volume comes more need for operational excellence. Ensuring that you have linkage between authorization, settlement, or refund flows is extremely important and makes reconciliation much simpler, especially during times of extraordinary volume."

The more payments you capture, the more downstream volume your teams have to manage. If authorization, settlement, and refund data aren't connected, resolving a single issue can pull payments, finance, customer support, and your provider into the same investigation.

That makes reconciliation part of peak readiness too, and the work to connect that data needs to happen now, while your team still has time to do it properly.

Are you ready for peak and what comes after?

Peak season tests every part of your payments operation, from how your stack holds up under load to how quickly your team can read a change in performance and how cleanly finance can reconcile in the weeks that follow. 

The merchants who come through it best are the ones who have tested their limits, set their baselines, agreed on their responses, and connected the data that ties it all together before the first Black Friday transaction arrives. If you want to pressure-test your setup against any of the areas above, our team can walk through it with you.

‍