Payment Page uses authenticated WordPress REST API routes in wp-admin and public provider callbacks on payment forms. A security or performance tool that disables the REST API, strips required request headers, blocks the callback route, or serves stale payment-form HTML can interrupt those flows.

REST API and cache checks#

  1. Reproduce the issue with Payment Page 1.5.3, the current WordPress release supported by the plugin, and a current backup.
  2. Check the browser network response and WordPress/PHP logs for the exact failing route and status. Do not disable site security globally as a first step.
  3. Confirm that the relevant /wp-json/payment-page/v1/ route is reachable with the authentication or provider signature it requires.
  4. Purge the specific page from every applicable cache and verify that the HTML is regenerated. Payment Page marks pages containing its form as non-cacheable, but a cache layer can ignore that signal.
  5. If temporarily disabling one plugin reproduces or resolves the problem, record the plugin version, setting, failing URL, response, and minimal steps before contacting support.

Do not expose API keys, webhook signing secrets, customer data, or payment details in screenshots or logs sent to support.

Theme or label-layout conflicts#

The old version of this page recommended an absolute-position CSS override for every theme. That rule has been removed because it can break responsive layouts and does not establish the cause of a conflict.

First reproduce the issue with a default WordPress theme and no custom CSS. If the theme is responsible, use the browser's computed styles to identify the exact conflicting selector and scope any override to the affected form and theme. The Payment Page support form can be used to share a minimal reproduction.