BazPay for WooCommerce

What it needs

Nothing exotic. If your store already takes card payments through any modern gateway, it almost certainly clears this list. The two that catch people are the permalink setting and a security plugin sitting in front of the REST API.

Install and connect

Three routes, same result. Pick whichever matches how the site is normally deployed — a managed host with no shell access is fine.

1. Add the plugin

   From the admin: Plugins → Add New → Upload Plugin, then the zip. From a shell: the WP-CLI line below. From a versioned deploy: require the package in Composer and let your pipeline ship it like any other dependency.

2. Paste the test keys

   WooCommerce → Settings → Payments → BazPay. The publishable key mounts the card fields in the browser; the secret key stays on the server. Both are visible in the dashboard the moment you sign up — there is no approval step for sandbox access.

3. Register the webhook

   The plugin writes its own endpoint into your BazPay account on first save. Confirm it landed, because everything downstream depends on it: the route is /wp-json/bazpay/v1/webhook on your own domain.

4. Place a sandbox order

   Use a test card from the testing guide and watch the order move to Processing on its own. If it stays on hold, jump to when it misbehaves — it is nearly always the webhook.

5. Swap in live keys

   Once underwriting returns them. Settings, method toggles and the webhook registration all carry over; only the key pair changes. The go-live checklist has the twelve checks worth running first.

# install and activate from WP-CLIwp plugin install bazpay-for-woocommerce --activate​# set the keys without opening the adminwp option patch update woocommerce_bazpay_settings \  publishable_key pk_test_4c81…wp option patch update woocommerce_bazpay_settings \  secret_key sk_test_9f2c…​# confirm the gateway registeredwp wc payment_gateway list --user=1 --fields=id,enabledbazpay        truebazpay_ideal  true

Works on any host with shell access. The option keys are stable across 3.x, so this is safe to put in a provisioning script.

Block and classic checkout

WooCommerce currently ships two checkout templates, and a large share of live stores run the older one. The plugin registers for both, so the template you use is your decision rather than ours.

• Block checkout Registered as a payment-method type through the Blocks API. Method names and icons come from the Store API, so they stay correct when you toggle a method in the dashboard.
• Classic shortcode A conventional gateway class rendering its fields in payment_fields(). Heavily customised classic checkouts keep working, including one-page checkout plugins.

Both templates mount the same hosted fields, so the PCI position is identical. The card inputs are iframes served from our domain; your theme styles the frame around them, and the card number is posted from the shopper's browser straight to us.

Order status mapping

Every payment state we publish maps onto a WooCommerce status, and the move happens when the signed event lands. Nothing here waits for the shopper to return to the site.

Refunds work from the order screen exactly as they do for any WooCommerce gateway: press Refund, enter an amount, and choose to refund through BazPay rather than manually. Partial refunds are unlimited in count up to the captured total.

Methods at checkout

Methods are toggles in the BazPay dashboard, and the checkout picks them up on the next page load. There is no per-method contract to sign and no second onboarding.

• Cards, including Cartes Bancaires routing for French issuers.
• iDEAL, Bancontact, BLIK, Przelewy24 and EPS for the markets that expect them.
• Apple Pay and Google Pay, with the placement toggles described above.
• SEPA Direct Debit, where the mandate is captured during checkout.
• Pay by bank for account-to-account, where it is available.

You can also restrict a method by billing country so a Dutch shopper sees iDEAL and a Polish one sees BLIK, without either seeing a wall of irrelevant logos. The full matrix of markets, currencies and refund behaviour is on the method reference.

Subscriptions

The plugin integrates with WooCommerce Subscriptions. The first payment is customer-initiated and authenticates normally; renewals are merchant-initiated against the stored credential, which is what keeps them out of a 3-D Secure challenge the shopper is not present to answer.

• Card subscriptions use a network token where the scheme supports one.
• SEPA subscriptions reuse the mandate signed at the first payment.
• A failed renewal returns the issuer reason code, so retry rules can be selective.
• Changing the payment method on an existing subscription re-authenticates once.

Dunning, retry schedules and proration remain WooCommerce's job. We supply the outcome and the reason; the store decides what to do about it. If you are building billing logic yourself rather than through the plugin, recurring billing covers the API side.

When it misbehaves

In three years of WooCommerce installs, nearly every "the plugin is broken" ticket has been one of five things. They are worth checking before writing to us, because four of them are fixable in under a minute.

# is the REST route reachable from outside?curl -i https://shop.example/wp-json/bazpay/v1/webhook​# healthy: the route exists and rejects an unsigned GETHTTP/2 405allow: POST​# 404 means permalinks are Plain, or REST is disabled# 403 means a security plugin or the WAF is in front of it

Run it from somewhere other than the web server itself — half of these failures are a firewall that trusts localhost.

Still stuck? Turn on logging in the plugin settings and reproduce the order. WooCommerce → Status → Logs, source bazpay, gives you the request id for every call. Send us that id rather than a description of the symptom and the reply is usually one message rather than five. The webhooks guide covers signature verification and the retry ladder in full.

Common questions

Does the plugin work with the WooCommerce block checkout?

Yes, and with the classic shortcode checkout at the same time. The plugin registers a Blocks payment-method type alongside the legacy gateway class, so a site mid-migration can run one template on one page and the other elsewhere without a second configuration.

Do I still need a PCI audit if I take cards on my own WordPress site?

You stay at SAQ A. The card fields are BazPay iframes served from our domain, so the primary account number is never posted to your WordPress installation and never touches your database or your logs. A compromised theme or plugin cannot read a PAN that never arrived.

Can I keep my current gateway enabled while I test BazPay?

Yes. WooCommerce allows several gateways at once, and ours does not claim the checkout exclusively. A common cut-over is to enable BazPay for one method — usually iDEAL or Bancontact — watch a week of real orders, then move the card traffic.

What happens if the shopper closes the tab immediately after paying?

The order still completes. The status change is driven by the signed webhook we send server-to-server, not by the shopper returning to the thank-you page. The return URL is a convenience for the shopper; it is not what confirms the money.

Is there a fee for the plugin itself?

No. Every connector is free and released under GPL-3.0. You pay the transaction pricing published on the pricing page, and nothing for the software or for the sandbox.