A newly confirmed WooCommerce PayPal Standard bug can cause online stores to make repeated, unnecessary API requests to WordPress.com. The issue affects the Transact account verification mechanism and can generate multiple blocking HTTP requests during a single page load, potentially slowing down storefronts, shopping carts and background tasks.
The problem was reported on November 12, 2026, in the official WooCommerce GitHub repository. According to the investigation, affected installations repeatedly request PayPal merchant account information even after the remote service has rejected the connection. Because failed responses are not cached, WooCommerce continues sending the same requests whenever the payment gateway is initialized.
In one reproducible test, a single shopping cart page generated 11 separate account lookup requests. On the WordPress.com infrastructure side, the problem was associated with approximately 20 million rejected account lookups per day, primarily originating from a few hundred stores.
The issue is particularly significant because the requests are synchronous and may have a timeout of up to 60 seconds each. Although the reported results do not establish that every affected store experiences slow checkout, the underlying behaviour can create unnecessary server load and increase response times when remote requests are delayed.
What Is the WooCommerce PayPal Standard API Request Bug?
The problem was documented in WooCommerce GitHub issue #70937 – PayPal Standard: a failed Transact account lookup is never cached.
WooCommerce includes mechanisms for verifying whether a store has completed the necessary PayPal account configuration to use its Transact-based payment integration.
When the relevant onboarding process has been completed, the payment gateway retrieves information about two account types:
- Merchant account: identifies the merchant’s account within the Transact infrastructure.
- Provider account: identifies the PayPal provider configuration associated with that merchant.
These details are retrieved through the WordPress.com API infrastructure.
Under normal conditions, WooCommerce stores successfully retrieved account information in a local cache for 24 hours.
This prevents the store from requesting identical information during every page load.
However, the reported bug reveals an important difference between successful and unsuccessful responses.
When an account lookup succeeds, its result is cached.
When the lookup fails, WooCommerce returns a null value without recording the failure in the cache.
As a result, the next attempt to check the account repeats the same remote request.
This behaviour can continue indefinitely while the underlying account or connection problem remains unresolved.
Which HTTP Errors Trigger Repeated Requests?
The original report identifies several conditions that can cause the account lookup to fail.
These include:
- HTTP 401 Unauthorized: the remote service rejects the authentication credentials.
- HTTP 403 Forbidden: the request is authenticated or recognized but is not permitted.
- HTTP 404 Not Found: the requested account or resource cannot be found.
- Network errors: the request fails because of a connection problem, timeout or another communication failure.
In the reproduction scenario, a simulated failed response included:
HTTP/1.1 401 Unauthorizedwith the following JSON error:
{
"code": "transact_authentication_failure"
}This response was used to reproduce the issue under controlled conditions. It should not be interpreted as the exact response returned by every affected production store.
The central problem is not the HTTP error itself. Remote APIs can legitimately reject requests.
The problem is that WooCommerce does not temporarily remember the failed lookup and therefore repeats it unnecessarily.
A Single WooCommerce Cart Page Generated 11 API Requests
The WooCommerce developer who submitted the report measured the number of account lookups generated during different requests.
The test used a controlled environment in which the remote service’s responses were simulated.
The results revealed that the number of repeated requests depended on the type of page being accessed.
| Page or request | Failed account lookups |
|---|---|
| Homepage | 3 |
| Shop page | 3 |
| Shopping cart | 11 |
| Store API cart request | 3 |
| Second homepage visit | 3 |
The same pattern appeared when the merchant account lookup returned HTTP 401 or HTTP 404.
It also occurred when the merchant account request succeeded but the PayPal provider account lookup returned HTTP 404.
The cart page was particularly affected, generating 11 account lookups during a single request.
What Happens When the API Requests Succeed?
The investigator also performed a control test in which both the merchant and provider account lookups returned successful responses.
The results were substantially different.
| Page or request | Successful account lookup requests |
|---|---|
| First homepage visit | 2 |
| Shop page | 0 |
| Shopping cart | 0 |
| Store API cart request | 0 |
| Second homepage visit | 0 |
When the requests succeeded, WooCommerce stored their results and reused the cached account information.
When they failed, the same lookups continued to run.
These measurements demonstrate that the problem is specifically related to handling failed API responses rather than an inherent need to check PayPal account information repeatedly.
Approximately 20 Million Rejected Requests Per Day
The original report includes operational information from the WordPress.com infrastructure used by the Transact integration.
According to the investigator, the repeated account lookups were responsible for approximately 20 million rejected API requests per day.
Most of those requests originated from a few hundred stores.
Some of the most active installations were generating more than 10 requests per second.
These figures describe aggregate rejected account lookups observed on the remote infrastructure. They do not mean that every WooCommerce store makes millions of requests or that millions of customers experience payment failures.
The investigation also identified a common characteristic among the most active installations.
Many had already been marked as disconnected by WordPress.com, but their local WooCommerce installations still contained old connection tokens.
Consequently, the stores continued attempting authenticated requests that the remote service would reject.
Because the failed results were not cached, the requests continued repeatedly.
Root Cause: TransactAccountManager Does Not Cache Failed Lookups
The problem was traced to the WooCommerce class:
Automattic\WooCommerce\Gateways\PayPal\TransactAccountManagerThis class manages merchant and provider account information for the PayPal Transact integration.
The relevant method is:
get_transact_account_data()Its responsibility is to retrieve account information from the local cache or request fresh data when necessary.
The existing implementation follows this general logic:
- Determine the cache key for the requested account.
- Attempt to retrieve the account information from local storage.
- If the information is unavailable or expired, contact the remote service.
- If the request succeeds, cache the result.
- If the request fails, return null without caching the failure.
The problematic behaviour occurs in the final step.
The Exact PHP Logic Responsible for Repeated Requests
The relevant part of the implementation follows this structure:
$transact_account = $this->get_transact_account_from_cache(
$cache_key
);
if ( empty( $transact_account ) ) {
$transact_account = 'merchant' === $account_type
? $this->fetch_merchant_account()
: $this->fetch_provider_account();
if ( empty( $transact_account ) ) {
return null;
}
$this->update_transact_account_cache(
$cache_key,
$transact_account
);
}
return $transact_account;Notice that the cache is updated only after a successful lookup.
If the remote request fails, the method returns immediately.
No temporary failure record is stored.
When the method is called again, WooCommerce finds no valid cached account information and makes another remote request.
The cycle repeats until the account lookup succeeds or another condition prevents the request from being performed.
The behaviour is visible in the official WooCommerce TransactAccountManager source code reference.
Why Does WooCommerce Call the Same Method Multiple Times?
The repeated requests originate from the payment gateway’s account verification logic.
The relevant method is:
WC_Gateway_Paypal::should_use_orders_v2()This method determines whether the gateway should use the PayPal Orders v2 integration.
It checks several conditions, including whether the store has a usable Jetpack connection and whether the required Transact merchant and provider accounts are available.
The method can be called when the payment gateway is initialized and from other parts of WooCommerce during a request.
Consequently, a single page load may invoke the same account verification logic multiple times.
If the account data is cached, these checks are relatively inexpensive.
If the remote lookup fails and no failure is cached, every invocation may trigger another outgoing HTTP request.
This explains why a shopping cart page can generate substantially more lookups than a basic storefront page.
Why a Disconnected Jetpack Connection Can Make the Problem Worse
The report identifies a particularly important condition involving the Jetpack connection used by WooCommerce.
The gateway checks the connection through a method similar to:
$jetpack_connection_manager->is_connected()However, this check can indicate that the store still has a connection token without proving that WordPress.com currently accepts that token.
For example, a store may retain an old token even after its connection has been invalidated remotely.
The local connection check may still succeed.
WooCommerce then attempts to retrieve Transact account information.
WordPress.com rejects the request, potentially returning HTTP 401.
Because WooCommerce does not cache the failed lookup, another request is made during the next account check.
In this situation, the problem can persist until the connection is repaired, the integration is changed or the underlying caching behaviour is corrected.
How Can Repeated API Requests Slow Down a WooCommerce Store?
The affected requests are synchronous.
This means the PHP process executing the request may wait for the remote API response before continuing.
The configured request timeout can reach 60 seconds.
That does not mean every failed lookup takes 60 seconds. An API returning HTTP 401 immediately may respond quickly.
However, slow connections, network failures or delayed upstream responses can make repeated lookups significantly more expensive.
Slower Storefront Responses
If WooCommerce performs several blocking remote calls while generating a page, the total processing time can increase.
This may affect pages where the PayPal gateway is initialized or its availability is checked.
Visitors could experience longer loading times even when they are not actively trying to pay with PayPal.
Shopping Cart Performance Problems
The original reproduction recorded 11 account lookups on the cart page.
If one or more of these remote requests takes an unusually long time, the page may be delayed.
The same concern applies to cart-related Store API requests when they trigger the affected payment gateway logic.
The report does not establish a specific percentage increase in checkout loading time across production stores.
Nevertheless, the repeated synchronous requests create an avoidable performance dependency on an external service.
Additional PHP Worker Load
PHP workers are responsible for processing dynamic requests in many WooCommerce hosting environments.
When a worker is waiting for an external API response, it may remain occupied without completing the customer’s request.
If multiple customers visit the store simultaneously and the same remote lookup problem occurs, more PHP workers may spend time waiting for external responses.
On resource-constrained hosting, this can contribute to slower responses and increased pressure on the available worker pool.
WP-Cron and WP-CLI Delays
The problem is not limited to browser requests.
The original report confirms that WordPress command-line operations and scheduled tasks can also trigger the affected account checks.
This can create unnecessary outbound traffic during background processing.
Depending on which operations are being executed, slow remote calls may increase the time required for maintenance jobs or automated tasks to finish.
Potential Checkout Disruption
If the payment gateway requires remote account verification during checkout, repeated failed lookups may affect the responsiveness of payment-related requests.
In extreme cases involving long network delays and limited server resources, this could contribute to request timeouts.
However, the confirmed issue is excessive API traffic and a payment gateway fallback, not a demonstrated universal checkout outage or direct failure of every PayPal payment.
WooCommerce May Silently Fall Back to the Older PayPal Flow
The issue has another important consequence beyond performance.
According to the original report, affected stores can silently fall back to the non-Orders-v2 PayPal payment flow when Transact account verification fails.
The reason is that WooCommerce cannot confirm the required merchant and provider account information.
From the gateway’s perspective, the conditions required to use Orders v2 are not satisfied.
As a result, the integration can choose the older payment-processing path.
This does not automatically mean that PayPal stops accepting payments.
However, administrators may be unaware that their store is no longer using the intended integration path.
Such changes can complicate troubleshooting, particularly if the store relies on specific payment behaviour or has recently completed a migration to newer PayPal functionality.
Which WooCommerce Versions Are Affected?
The bug was introduced with the Transact account management component added in WooCommerce 10.5.0.
The original report identifies the following version information:
| Component | Version or status |
|---|---|
| WooCommerce | 10.5.0 and later code containing the affected mechanism |
| Confirmed reproduction | 11.3.0-rc.2 |
| Payment gateway | PayPal Standard with completed Transact onboarding |
| Remote service | WordPress.com Transact API |
| Successful lookup cache | 24 hours |
| Failed lookup cache | Not implemented in the affected code |
| Remote request timeout | Up to 60 seconds |
Not every installation running these WooCommerce versions is affected.
The issue requires the relevant PayPal Standard integration and account verification path to be active, along with failed account lookups.
Stores using an entirely different payment gateway are not automatically exposed to this specific behaviour.
Is This the Same as the WooCommerce PayPal Payments Plugin?
No. It is important to distinguish the legacy PayPal Standard integration from the modern WooCommerce PayPal Payments extension.
PayPal Standard is an older integration that WooCommerce has been gradually retiring.
The modern PayPal Payments extension provides a different integration with PayPal’s current payment services.
WooCommerce published an official advisory in June 2026 explaining that merchants should plan their migration away from PayPal Standard.
According to the advisory, PayPal Standard had already been hidden from new installations for several years, and the relevant legacy registration mechanism had been removed from normal core setup in WooCommerce 8.9.
Existing stores and legacy configurations can still retain PayPal Standard functionality, which is why the affected integration code remains relevant.
The modern PayPal Payments extension also includes migration handling intended to disable PayPal Standard once a merchant successfully connects to the newer integration, subject to safeguards for active subscriptions.
More information is available in the official WooCommerce advisory about the retirement of PayPal Standard.
The excessive Transact lookup issue should not be described as a confirmed bug affecting every store using the separate PayPal Payments extension.
How to Diagnose Repeated PayPal API Requests in WooCommerce
Administrators investigating slow WooCommerce pages should first determine whether their installation uses the affected PayPal Standard configuration.
1. Check the Installed WooCommerce Version
In WordPress, open the Plugins section and identify the installed WooCommerce version.
Alternatively, using WP-CLI:
wp plugin get woocommerce --field=versionThe issue was introduced with the relevant Transact account management logic in WooCommerce 10.5.0.
A matching version alone is not enough to confirm the problem.
2. Check Whether PayPal Standard Is Active
Open:
WooCommerce
Settings
PaymentsCheck whether PayPal Standard is available and enabled.
In legacy configurations, the gateway may remain active even though it is no longer presented as a default option for new stores.
If PayPal Standard is not active, investigate other causes of slow storefront responses before attributing the problem to this issue.
3. Inspect the Transact Onboarding State
The affected path is associated with stores that have completed Transact onboarding.
Administrators with WP-CLI access can inspect relevant configuration values without printing stored payment credentials.
For example:
wp eval '$s = get_option("woocommerce_paypal_settings", []); echo "Enabled: " . ($s["enabled"] ?? "unknown") . PHP_EOL; echo "Transact onboarding: " . ($s["transact_onboarding_complete"] ?? "unknown") . PHP_EOL;'This command reads the settings and prints only the gateway state and onboarding indicator.
It does not modify the store configuration.
Pay attention to a result showing PayPal Standard enabled and Transact onboarding completed.
That combination is relevant to the reported problem, but it is not proof that account lookups are failing.
4. Look for Repeated Requests to the Transact Account Endpoint
The reported lookup mechanism communicates with WordPress.com through a Transact endpoint.
The relevant API paths contain:
/transact/accountAdministrators can investigate outgoing HTTP requests using application performance monitoring, WordPress HTTP request instrumentation or temporary diagnostic logging.
Look for repeated requests returning:
401 Unauthorized
403 Forbidden
404 Not FoundAlso investigate network errors associated with the same endpoint.
If multiple failed requests occur during a single page load, the behaviour may match the original report.
Application-level monitoring is often more useful than Apache or Nginx access logs for this diagnosis because the problematic calls are outgoing requests generated by PHP.
5. Compare Homepage, Shop and Cart Behaviour
The original investigator observed the greatest number of lookups during shopping cart requests.
Repeat controlled page requests and compare the number of outgoing Transact account lookups.
For example, investigate:
- Homepage requests.
- Product catalogue requests.
- Shopping cart requests.
- Store API cart requests.
- Repeated requests to the same page.
If every visit triggers the same failed account lookup again, the cache is not suppressing the repeated operation.
Testing should ideally take place in a staging environment, particularly if additional instrumentation is required.
6. Check the WordPress.com Connection Status
The report found that many affected stores still held connection tokens even though WordPress.com had already marked the connections as disconnected.
Therefore, a local indication that the site is connected may not be sufficient.
Check whether the connection is actually accepted by the remote service.
If authentication requests are rejected, investigate whether the connection needs to be reauthorized.
Do not publish connection tokens, authorization headers or complete authenticated request logs.
Why Clearing the WooCommerce Cache May Not Fix the Problem
Clearing the WordPress object cache or WooCommerce transients is unlikely to solve the underlying issue by itself.
The problem exists because failed lookups are not stored as temporary cache entries.
Removing existing cache entries can actually cause WooCommerce to perform additional account lookups until valid data is retrieved.
The relevant cached account information uses options such as:
woocommerce_paypal_transact_merchant_account_live
woocommerce_paypal_transact_provider_account_liveThese options are used to store successful account information.
Deleting them without understanding the integration state is not a universal fix.
If the remote connection is still invalid, WooCommerce may simply repeat the same failed requests.
The permanent solution needs to address the treatment of failed lookups or repair the underlying connection.
How to Reduce Excessive PayPal Standard API Requests
The appropriate response depends on whether the store is still actively using PayPal Standard and whether the connection can be repaired.
Check Whether the Connection Can Be Reauthorized
If WordPress.com rejects the stored authentication token, verify the connection and follow the supported reconnection procedure for the installed integration.
A valid connection may allow WooCommerce to retrieve account information successfully.
Once valid account data is returned, the existing 24-hour caching mechanism can prevent unnecessary repeated requests.
Reconnecting is not guaranteed to solve every case. HTTP 404 responses caused by missing account data may require additional investigation.
Review Whether PayPal Standard Is Still Required
Stores that no longer use PayPal Standard should verify whether the legacy gateway remains enabled unnecessarily.
Leaving an unused payment integration active may expose the store to additional configuration checks and unnecessary background activity.
However, disabling an active payment method without providing an alternative can interrupt sales.
Before making any change, confirm which gateway customers actually use.
Consider Migrating to WooCommerce PayPal Payments
WooCommerce officially recommends moving away from PayPal Standard to the modern PayPal Payments extension.
Migration can eliminate the need to rely on the legacy integration, but it must be performed carefully.
Administrators should verify:
- Current PayPal account configuration.
- Existing payment methods.
- Active and pending subscriptions.
- Compatibility with the installed WooCommerce version.
- Checkout behaviour after migration.
- Refund and order status synchronization.
- Any custom integrations relying on legacy PayPal functionality.
In particular, stores with subscriptions should not simply disable PayPal Standard before reviewing how existing recurring payments are handled.
The official migration guidance includes safeguards for subscriptions associated with the older gateway.
Avoid Blocking WordPress.com Requests as a Shortcut
Blocking all outbound traffic to WordPress.com is not a reliable solution.
The affected code already repeats requests when they fail.
Forcing the requests to return an error may therefore preserve or worsen the condition.
Broad network restrictions can also affect unrelated WordPress or WooCommerce services.
A better approach is to correct the integration state or apply a verified fix that avoids repeated lookups after failure.
What Should the WooCommerce Fix Change?
The official issue proposes several changes to the Transact account verification mechanism.
1. Cache Failed Account Lookups Temporarily
The most important proposed improvement is to remember failed requests for a limited period.
This is commonly called negative caching.
Instead of immediately repeating the same failed request, WooCommerce would store a temporary failure state.
During the cache period, further checks could return the known failure result without contacting WordPress.com again.
The cache must expire eventually so that a repaired connection can be detected.
2. Introduce Backoff for Repeated Failures
Another proposed improvement is to delay subsequent attempts after repeated errors.
For example, the integration could retry account verification after a controlled interval rather than during every page request.
The exact backoff policy has not yet been finalized in an approved patch.
3. Treat HTTP 401 as an Invalid Connection State
The issue suggests that HTTP 401 responses should be interpreted as an indication that the stored connection cannot currently be used for the PayPal integration.
In that situation, WooCommerce should avoid repeatedly sending authenticated requests with credentials that the remote service rejects.
A longer retry delay may be appropriate until the connection is repaired or reauthorized.
4. Avoid Duplicate Lookups Within a Single Request
Even without persistent caching, WooCommerce should not need to ask the remote service for the same account information 11 times during one cart request.
The proposed changes therefore include preventing repeated lookups within the same PHP request.
This would directly address the excessive request counts demonstrated in the reproduction tests.
5. Reconsider Remote Calls From the Gateway Constructor
The issue also suggests reconsidering whether remote account verification should take place while the payment gateway object is being constructed.
Gateway initialization can occur in different parts of the application, including requests that are not directly processing a PayPal payment.
Moving expensive network operations out of frequently executed initialization paths could reduce unnecessary dependencies on external services.
Has WooCommerce Released a Fix?
As of November 13, 2026, the original GitHub issue remains open.
It is officially labeled as a confirmed bug and categorized under payment-related issues.
The report contains a detailed explanation of the cause, reproduction results and proposed remediation.
However, no linked pull request or completed fix is shown in the issue at the time of review.
The latest public activity includes interest from a contributor in working on the problem, but that does not establish that a tested correction has been released.
Administrators should therefore verify the official issue and future WooCommerce release notes before assuming that an update resolves the repeated Transact lookup behaviour.
A WooCommerce update may include unrelated PayPal changes without necessarily addressing this specific caching defect.
Can This Problem Cause Failed or Duplicate PayPal Payments?
The confirmed problem involves repeated account verification requests and fallback behaviour in the PayPal integration.
The report does not demonstrate that the bug automatically creates duplicate PayPal transactions.
It also does not establish that all affected customers are unable to complete their purchases.
However, repeated blocking requests may reduce responsiveness during payment-related operations, especially when the remote service responds slowly.
The fallback from Orders v2 to the older PayPal flow may also change the payment-processing path used by an affected store.
If customers report payment problems, administrators should investigate the actual transaction status through PayPal rather than assuming that repeated Transact requests prove a failed payment.
Similarly, an order remaining in Pending payment does not automatically indicate that the customer was not charged.
Always confirm the payment provider’s transaction records before requesting another payment or changing an order’s financial status.
Does the Bug Affect WooCommerce Stores Without PayPal?
Stores that do not use the affected PayPal Standard integration are not automatically exposed to this specific issue.
The repeated account lookup occurs in the PayPal Standard Transact verification path.
A store using only Stripe, bank transfer or another independent payment gateway would not normally execute this specific account verification mechanism unless the affected PayPal integration was also present and active.
Likewise, the existence of a PayPal payment button does not establish that the store uses the legacy PayPal Standard Transact path.
The installed gateway and its configuration must be checked.
Why This Bug Matters for High-Traffic WooCommerce Stores
Online stores depend on the ability to process incoming requests quickly and predictably.
External API calls introduce dependencies on services outside the store’s own infrastructure.
Such calls are often necessary for payment processing, but they should be executed only when required and should handle failures efficiently.
Repeatedly requesting the same unavailable account information adds no value to the payment process.
Instead, it increases network traffic and may consume server resources.
For high-traffic WooCommerce installations, even small inefficiencies can become significant when they occur during thousands of page requests.
The problem is especially important when requests are synchronous and executed during page generation.
Store administrators should distinguish between necessary payment verification and redundant account status checks that can be cached or deferred.
Frequently Asked Questions
Why is WooCommerce making repeated requests to WordPress.com?
In the reported bug, PayPal Standard repeatedly checks Transact merchant and provider account information. Failed requests are not cached, so subsequent gateway checks send the same requests again.
Which WooCommerce versions are affected?
The relevant mechanism was introduced in WooCommerce 10.5.0. The issue was reproduced on WooCommerce 11.3.0-rc.2.
Does the bug affect every WooCommerce store?
No. It concerns the PayPal Standard Transact account verification path when account lookups fail. Stores without the affected integration are not automatically impacted.
Why does the cart page make more API requests?
The PayPal gateway’s account verification method is called from several places during request processing. In the reported reproduction, the cart page triggered 11 account lookups, compared with three on the homepage.
What does HTTP 401 mean in this situation?
HTTP 401 indicates that the remote service rejected authentication. A store may still hold a local connection token even when WordPress.com no longer accepts that connection.
Can this cause slow WooCommerce checkout?
Potentially. The account lookups are synchronous and may wait for remote responses. Repeated slow requests can increase page processing time, although the original report does not provide a universal checkout slowdown measurement.
Does PayPal Standard automatically stop working?
Not necessarily. The issue reports that affected stores can fall back to the older non-Orders-v2 payment flow when Transact account verification fails.
Does clearing the WordPress cache solve the problem?
Not by itself. The underlying bug is the absence of caching for failed account lookups. Clearing existing cache entries does not correct that behaviour.
Should I delete my Jetpack connection token?
No. Removing connection information without an appropriate recovery plan may disrupt other services. First investigate whether the remote connection is invalid and use a supported reconnection procedure if required.
Is this the same as the WooCommerce PayPal Payments plugin?
No. The reported issue concerns the PayPal Standard Transact integration. It should not automatically be attributed to the separate modern PayPal Payments extension.
Does the bug cause millions of failed customer payments?
No such conclusion is supported by the report. The approximately 20 million daily figure refers to rejected account lookup requests observed by WordPress.com, not to failed customer payments.
Is an official fix available?
As of November 13, 2026, the issue is open and confirmed, but no linked completed fix or released patch has been established.
What WooCommerce Store Owners Should Do Now
WooCommerce administrators using PayPal Standard should verify whether their installations have completed Transact onboarding and whether the associated WordPress.com connection is still valid.
If the store repeatedly receives HTTP 401, 403 or 404 responses from Transact account endpoints, investigate the connection state and measure how often these requests occur.
Particular attention should be paid to shopping cart requests, Store API operations and scheduled tasks that may initialize the affected gateway.
For stores that no longer require PayPal Standard, reviewing the migration to the modern PayPal Payments extension may be appropriate. Existing subscriptions and custom payment integrations must be evaluated before making changes.
Until an official fix is available, the safest approach is to identify the affected configuration, correct invalid connections where possible and monitor excessive outgoing API requests without introducing untested changes to the payment-processing code.
The confirmed issue demonstrates how an apparently small caching defect can create significant infrastructure traffic and potentially affect storefront responsiveness. Proper handling of failed external API requests is essential for reliable payment integrations, particularly in online stores where page performance and checkout availability directly affect sales.
[…] integration issues can also affect store performance and reliability. A separate example is the WooCommerce PayPal Standard bug involving repeated failed API requests, which demonstrates how integration behavior can influence storefront operations. That issue is […]