Audit your payment-gateway configuration

Checkout is the one screen you cannot afford to get wrong, and it is also the one most likely to carry a leftover. A test gateway still enabled, a live method with a confusing label, two options in an order that pushes the cheapest one to the bottom, a description written for a promotion that ended months ago. You only notice when a customer asks why they cannot pay.

This reads your full gateway lineup exactly as a shopper meets it, hands you a table, and then fixes only the labels and switches you approve. Card numbers and API secrets are never in the picture.

Audit the payment gateways on this WooCommerce store. Two passes, and the
first one changes nothing.

First pass, reads only: list every registered gateway and whether it is
enabled, then for each one pull its title, description, display order, and its
non-secret settings. Never show me any key or credential. Give me one table in
checkout order and flag anything that looks off: a test gateway still live, a
confusing or stale title or description, a live method buried at the bottom of
the order, or a gateway enabled that I probably do not want.

I will tell you what to fix. Only after I approve, update just those gateways,
changing only their enabled state, title, description, or order, and show me
each change before it saves. At the end, list every gateway you touched with
its old and new values.

Why this is safe to run

The first pass is all reads, and the plugin redacts every credential and secret field before it ever reaches the agent, so an audit cannot leak a key even if it tried. You get the checkout lineup as a table before anything moves.

The fix pass reaches one write ability, updating a gateway, and it is deliberately narrow: it can flip the enabled state, rename the title or description, or reorder, and that is the whole surface. It cannot write a credential, and it stays switched off until you enable it. Every change is shown before it saves, each call is checked against the capability of the user you bound the agent to, and every write lands in the Activity Log with the gateway it changed. If checkout reads wrong afterward, the log points you straight at the gateway to reopen.

Already connected? Skip the paste. Ask your agent for the “audit payment-gateway configuration” recipe, or just describe the job, and it runs the same two-pass flow on your own store.