Planning capacity for peak season in payments

If you are reading this in the third week of November, your White Friday arrangements are already set. What follows it is still open, and in this part of the world the next few peaks arrive in an awkward cluster.

Black Friday, branded White Friday across much of the Gulf, gets planned because the marketing team makes sure everyone knows the date. Less attention goes to the weeks after. The Dubai Shopping Festival usually runs from the middle of December to late January, which lays it across the year-end change freeze and the holiday leave season. Month-end salary flows arrive regardless, driven in the UAE by the Wage Protection System, and they do not move aside for a festival. Ramadan and Eid shift roughly 11 days earlier each year against the Gregorian calendar, so a plan built from last year's dates is wrong by almost two weeks before anyone opens it.

Put every peak on one calendar

The useful artifact is a single twelve-month calendar that the operations, support, risk and engineering leads all work from. Four layers belong on it:

• Commercial peaks: White Friday, the Dubai Shopping Festival and any campaign your larger merchants or partners have warned you about.
• The religious and public holiday calendar, with Ramadan and Eid at this year's dates, plus the days your partner banks and processors are closed in every country you settle in.
• Payroll: month-end salary dates, and for a card or wallet program the days just after payday when balances get spent.
• Your own constraints: change freezes, planned migrations, audit fieldwork and the leave your team has already booked.

The reason to put them on one page is the overlap. Each peak on its own is usually survivable. The week that hurts is the one where salary payments land in the middle of the festival, during the freeze, with a third of the team away. Mark every week where two or more layers coincide, and plan those in detail.

Most of the damage in peak season comes from two ordinary peaks landing in the same week.

Forecast the work, then the work behind it

A rough forecast from your own history is enough. Take daily volumes for the same event last year, broken down by the work they create: card authorizations, transfers, onboarding applications, support contacts. Apply your growth since then and move the dates where the calendar moved.

An illustrative run through the arithmetic. Say a card program handles 40,000 transactions on a normal day, and last year's festival weeks ran about 50 percent above that. If the program has grown by half since, the heavy days this year land near 90,000. If roughly one transaction in a thousand produces a support contact, contacts go from about 40 a day to about 90, before you count the extra contacts created by declines or delays. Those are round numbers chosen to show the shape of the problem, and your own ratios will be different, but the ratios are usually easy to pull from last year's data.

Then forecast the work that lags. A spending peak becomes a disputes peak several weeks later, on timelines the card scheme rules set for you, and a refunds peak once the returns come in. A marketing push also fills the onboarding queue, where adding reviewers late in the day tends to make things worse before it makes them better, for the reasons we set out in our post on KYC backlogs. Staffing the disputes team for December helps nobody if the evidence packs arrive in February. The same goes for reconciliation: more volume at more merchants means more unmatched items, and those take longer to clear when the people who understand them are on leave.

Plan support by hour. A daily total hides the hours when contacts actually arrive, and the pattern differs between a festival evening and a salary morning. Use last year's hourly curve for the same event where you have it. During Ramadan, working patterns change for a good part of the team and often for customers too, so those weeks need their own shift plan instead of a copy of the standard one.

Ask your partners the same questions

Your capacity is capped by the weakest link in the chain, and it is rarely your own system. Before each marked week, ask your processor, sponsor bank, KYC vendor and SMS or OTP provider what volume they have planned for and what rate limits apply to your connection. Ask what happens when you reach those limits, and what their support hours and freeze dates look like over the holidays. Check the rate limits in the contract against the ones in the API documentation, because the two do not always agree.

Ask for a named contact for the peak weeks as well. An escalation path that routes through a shared mailbox on 27 December is not an escalation path.

The freeze sits on top of the festival

Because the festival runs through the year-end change freeze, anything you might need to change during it has to be done before the freeze starts or pre-approved as a standard change. That list is usually short and predictable: merchant or velocity limit increases, fraud rule adjustments within an agreed range, access provisioning for temporary staff, extra capacity on a vendor or cloud setting. Agree the ceilings, who can authorize each one and how it gets logged, and write it down before people disperse for the holidays. We set out how to run that exception process in the change freeze post.

The last thing to do this month takes about an hour. Put next year's expected Ramadan and Eid dates on the calendar, line them up against month-end salary dates and your own audit and release plans, then see which weeks collide. That is where the hard week of 2026 will be, and knowing it in November gives you ten months to staff it.

Discuss your operations