Troubleshooting

By far the most common issue. The payment succeeded at Buckaroo but the push message never reached WooCommerce, or was rejected.

Start in Plaza, not WooCommerce. Open the transaction and look at the Logs tab. It shows every push attempt and the response your server gave, which tells you straight away which half of the connection failed.

If Plaza shows no push attempts at all, pushes aren't being sent for that store. Check that push messages are enabled in Plaza under Settings → Stores → Push settings, for the store whose Store key is in WordPress.

If the pushes failed with a timeout or connection error, the request never reached your store:

1. Are Buckaroo's IPs allowlisted? A firewall, WAF or hosting-level IP allowlist blocking them is the single most common cause. Check the current list against your rules. If the allowlist was set up a while ago, an address may have been added since.
2. Are the required ports open for inbound traffic from those addresses?
3. Is the store behind basic auth? Common on staging. Buckaroo can't authenticate.
4. Is the endpoint cached? A full-page cache or CDN in front of ?wc-api=wc_push_buckaroo will break it.

If Plaza shows the pushes being delivered successfully but WooCommerce didn't act on them:

5. Do the Secret keys match? If the key in WordPress differs from the one in Plaza, the signature check fails and the push is discarded. This often happens after a key is regenerated in one place but not the other.
6. Is default_charset UTF-8? A mismatch can corrupt incoming push data. The plugin warns about this on its settings page.
7. Check the log with debug mode on. A rejected push is logged.

You don't need to check the push URL itself. The plugin sends it with every transaction request, so it can't be misconfigured. What can be wrong is whether pushes are enabled for the store at all.

Once you've fixed the cause, you don't have to chase the affected orders manually. Buckaroo retries for three days, so recent orders may resolve themselves. For older ones, resend from Plaza: open the transaction and use Actions, or use Transactions → Overview → Filters → Actions → Bulk Push to resend a batch.

Bank Transfer and PayPerEmail are on hold by design until the customer actually pays.

Work down this list:

1. Is the method enabled, with Transaction mode set to Test or Live?
2. Is the method active on your Buckaroo contract? Check Plaza.
3. Does the cart total fall within the method's minimum and maximum order amount?
4. Does the customer's billing country and the cart currency match what the method supports? The Payment Methods list shows both per method.
5. For Riverty set to B2B, has the customer entered a company name? The method only appears when they have.
6. Have you cleared any page cache since changing the configuration?
7. For Apple Pay and Google Pay, is the button enabled for that page, and are you on a supported device?

• Confirm the Store key and Secret key have no leading or trailing whitespace. Copy-paste from Plaza often picks up a trailing space. Use the eye icon to check what's actually in the field.
• The Secret key applies to your whole account, the Store key is per store. Mixing up two stores' keys produces the same error.
• Confirm you saved the page before testing.
• If the keys are definitely right, check whether outbound HTTPS from your server to Buckaroo is blocked.

• "Failed to retrieve active subscriptions" means the credentials are wrong or unreachable. Run Test credentials first.
• "No active subscriptions found" means the credentials are fine but your Buckaroo contract has no methods active yet. Contact your account manager.
• Remember that auto-configure enables methods in Live mode. If you were expecting test mode, set them back afterwards.

Hosted Fields requires HTTPS with a valid certificate. A self-signed certificate on staging will stop the form loading.

Also confirm the Hosted Fields Client ID and Client Secret are filled in, from Plaza under Settings → Token registration. Without them the inline form has nothing to authenticate with.

As an interim step, set Credit and debit card method back to Redirect so cards keep working while you sort the certificate out.

• Check the button is enabled for that specific page. Product, cart and checkout are separate settings.
• Apple Pay needs a supported device with a card in Wallet. Google Pay needs a card saved to the Google account.
• Check the GUID (Apple Pay) or Gateway Merchant ID (Google Pay) is filled in.
• For Google Pay in production, the Google Merchant ID is also required. Without it the button works in test mode only.
• Clear any page cache. Cached product and cart pages are a common cause.

• Check the value on the method: a fixed amount like 1.50, or a percentage like 1%. Decimals must use a dot, not a comma.
• Check the tax class for fee and payment fee display settings under General Settings. A fee that looks wrong by exactly the VAT rate is usually one of these.
• Pay by Bank does not support fees at all.

• Did you use Refund via Buckaroo rather than the manual option? A manual refund sends nothing to Buckaroo.
• Is the original transaction settled? Some methods can't be refunded until settlement.
• Has the order already been refunded in Plaza? A double refund will be rejected.
• For an order captured in more than one step, refund against the specific capture. Please refer to the documentation about order management.

Decline reasons come from the issuing bank, not from Buckaroo or WooCommerce. The specific code is visible in Plaza under the transaction. See Decline codes for what each one means. "Do Not Honor" in particular is more nuanced than it sounds.

It isn't. The plugin declares compatibility with the Cart & Checkout Blocks feature, so it should not appear in that list.

If you still see the Site Editor notice suggesting you switch back to the classic checkout, another plugin on your site is the incompatible one. Check the list of extensions the notice names.

If Buckaroo is genuinely named there, confirm you're on the latest version.

1. Check the release notes for the versions you moved through. A breaking change may be documented.
2. Confirm your WordPress, WooCommerce and PHP versions are still in the supported range. A WooCommerce major release can move the goalposts.
3. Clear any page and object cache.
4. Deactivate other payment or checkout plugins temporarily to rule out a conflict.

That warning means the method was in Test mode when the order was placed, so no real money moved. Check Transaction mode on that method and set it to Live.

It's worth checking every method rather than just the one, since mode is set per method.