Paysafe reported another disruption involving its PagoEfectivo QR-payment provider on November 13, extending a series of recurring failures that have repeatedly forced the payments company to redirect transaction traffic away from its primary infrastructure.
The latest incident, INC0330102, affected PagoEfectivo QR Payments. At 01:46 UTC, Paysafe confirmed that traffic had been successfully redirected to an alternative solution and that affected services were operational. At 02:17 UTC, the company announced that its primary QR provider had recovered, allowing traffic to return to the original route.
The two updates were 31 minutes apart, but they do not establish the disruption’s total duration. Paysafe did not disclose when the underlying failure began, how many payments were affected or what caused the provider’s services to deteriorate.
The incident followed another QR-provider failure resolved at 20:48 UTC on November 12. Less than five hours after Paysafe restored traffic to its primary provider, the company was reporting another successful failover.
The same route came back into use, and then it needed replacing again.
Seven QR-provider incidents recorded since November 9
Paysafe’s public status history records seven separate QR-provider incidents between November 9 and the early hours of November 13, establishing a recurring pattern rather than an isolated technical problem.
The sequence began on November 9, when Paysafe identified degradation at its QR partner at 07:22 UTC. The provider recovered, and traffic returned to the primary route by 07:44 UTC.
Two further incidents appeared on November 10. The first was identified at 05:51 UTC and resolved at 07:21 UTC. Later that day, a separate disruption prompted another switch to alternative infrastructure, with services operational through the backup at 17:06 UTC and the primary provider restored at 20:29 UTC.
On November 11, Paysafe confirmed another successful diversion at 20:31 UTC before returning to the primary provider at 21:18 UTC.
November 12 brought two more incidents. The first was identified at 01:04 UTC, with backup traffic operational by 01:34 UTC and the primary provider restored at 01:36 UTC.
The second was recorded that evening under INC0330079. Paysafe confirmed successful failover at 20:27 UTC and returned traffic to the primary provider 21 minutes later.
There were two on November 10, two on November 12, and the days between did not stay clear either.
The November 13 recurrance continued almost exactly the same operational sequence: traffic diverted to an alternative provider, services confirmed operational, the primary provider restored, and traffic returned.
This pattern was visible before the latest week. DaveFinances documented three QR-provider disruptions on November 4, including incidents INC0328507, INC0328564 and INC0328629.
Earlier reporting also identified repeated QR failovers during September and October, with at least ten recorded incidents between September 22 and October 3.
Repeated failovers leave the primary provider unexplained
Paysafe’s incident notices demonstrate that its alternative processing route has repeatedly restored affected services while the primary provider remained degraded.
The failover is visible; the trouble behind it, not really.
For merchants, the relevant recovery time is not always the timestamp when Paysafe formally closes an incident. In several cases, the company reported that payment services were fully operational through alternative infrastructure before announcing that its primary provider had recovered.
Consequently, the time between the first incident notice and final resolution cannot automatically be treated as continuous merchant downtime.
The records also show that Paysafe repeatedly resumed primary-provider processing after receiving confirmation that the partner had restored its services. They do not explain the technical criteria used to authorize those returns.
There is no published root-cause analysis establishing whether the incidents originated from the same technical fault, separate failures within one provider’s systems or problems affecting an upstream dependency.
Paysafe has not identified the QR partner in these notices. Although its Peruvian payment infrastructure includes relationships with companies such as Niubiz, the available incident records do not establish which provider was responsible.
The recurring disruptions also raise an operational question about whether the alternative route is designed primarily for temporary recovery or could support longer periods of processing. Paysafe has not disclosed its routing architecture, fallback capacity or criteria for keeping transactions on the secondary service.
It is quite a gap between knowing where traffic went and knowing why it had to move.
The latest incidents follow a seperate, more extensive PagoEfectivo disruption that began on October 29 and was formally resolved on November 1.
During that earlier incident, Paysafe disclosed cybersecurity remediation work, assistance from external specialists and the permanent deactivation of certain merchant API credentials. Affected merchants were instructed to obtain replacement credentials through a secure process.
DaveFinances previously examined the PagoEfectivo restoration and subsequent merchant-notification failures reported on November 1 and 2.
Those events provide relevant operational background, but Paysafe has not established a technical connection between the October incident, the subsequent credential replacements and the QR-provider disruptions continuing through November 13.
Peru introduces new requirements for QR-payment providers
The repeated incidents come as Peru updates the regulatory framework governing QR payments and the technical providers supporting them.
On November 6, the Banco Central de Reserva del Perú published Circular No. 0028-2026-BCRP, establishing a new national QR-payment standard and requirements covering interoperability, operational continuity, security and transaction traceability.
The regulation took effect on November 7, with transitional arrangements allowing existing QR systems to continue operating while providers adapt to the new standard.
Among its requirements, regulated entities must maintain incident-management and business-continuity procedures, implement appropriate operational risk controls and preserve records of transactions initiated through QR codes.
The framework also requires existing participants performing covered functions to regularize their registration by December 31, 2026. Existing and new QR formats may coexist during the transition period, which extends through March 31, 2028.
The regulation does not establish that Paysafe or its unnamed QR partner breached any requirement. Its introduction nevertheless places operational continuity and interoperability within a more explicit regulatory framework for Peru’s QR-payment infrastructure.
PagoEfectivo’s QR service operates within the Peruvian payments ecosystem, where digital-wallet and banking connections allow merchants to accept transactions through local payment methods.
A recurring problem at one processing partner can therefore affect a specific merchant-payment route without demonstrating an outage across Peru’s banking system or every wallet using the national QR infrastructure.
Paysafe has not quantified the financial impact
For NYSE-listed Paysafe (PSFE), the latest incident provides further evidence of recurring service interruptions within one of its Latin American payment operations, but not a measurable financial loss.
The company has not disclosed failed transaction counts, affected payment values, merchant compensation, lost processing revenue or contractual penalties associated with the November QR incidents.
The customer-facing numbers, those are still absent.
The public records support a narrower assessment: Paysafe’s backup infrastructure has repeatedly restored QR-payment availabilty, while the primary-provider arrangement has continued to experience separate reported failures.
The distinction between temporary service recovery and sustained provider reliability is evident from the incident timeline itself. A successful switch to backup processing resolves the immediate availability problem, but the subsequent return to a failing primary route leaves the original dependency in place.
Paysafe’s disclosures do not establish whether the provider has implemented a permanent technical fix or whether the company is reviewing its routing arrangements following the repeated interruptions.
There is also insufficient information to determine whether the maintenence activities recorded across PagoEfectivo during November contributed to any of the QR incidents.
As of the November 13 resolution notice, Paysafe had confirmed that the affected services were operational and that traffic had returned to its primary provider. The incident was closed at 02:17 UTC.
What remains undocumented is the reason that the same recovery procedure has been required so frequently. An explanation of the provider’s recurring failures, the technical conditions behind returning traffic to the primary route and the actual volume of interrupted payments would establish the operational and financial consequences more clearly than the resolution notices currently allow.
Johan Shamshad is Editor-in-Chief at Dave Finances, covering financial markets, digital assets, trading platforms, brokers, fintech, payments and regulation. Since 2023, he has also worked as an editor at Gulf News, the UAE English-language newspaper published by Al Nisr Publishing LLC. His work focuses on market-moving developments, company disclosures, regulatory changes and trading infrastructure, with an emphasis on primary-source verification and practical context for traders and investors.