Configuration
Configure how the plugin behaves across your store: transaction descriptions, payment fee tax, the payment page language, age verification and logging.
All settings live under WooCommerce → Settings → Buckaroo Settings, split across five sections.
| Section | What's in it |
|---|---|
| General Settings | API credentials, transaction and refund descriptions, fee tax, payment page language |
| Payment Methods | The list of Buckaroo methods, with status and a link into each one's settings |
| Verification Settings | iDIN age and identity verification |
| Advanced Settings | Debug mode and where debug data is stored |
| Reports | The log viewer |
If you haven't added your API keys yet, start with Connect your Buckaroo account.
General settings
Below the API credentials card, General Options covers transaction, fee and locale settings.
| Setting | What it does | Default |
|---|---|---|
| Transaction description | The description your customer sees on their bank statement. | Order number |
| Refund description | Statement description for refunds. | Order number |
| Select tax class for fee | Which WooCommerce tax class applies to payment fees. | Standard |
| Payment fee display | Whether the fee is shown to the customer including or excluding VAT. | Excluding VAT |
| Payment page language | The language of Buckaroo's payment pages. | Dynamic |
Transaction description
Set a description your customers will recognise on their bank statement. Unrecognised descriptions are a common cause of chargebacks, so use something that clearly identifies your shop.
You can use these tags:
{order_number} → 1042
{shop_name} → Storename
{product_name} → First product on the order{shop_name} {order_number} renders as Storename 1042, which a customer is far more likely to recognise than an order number alone. Leave the field empty and the plugin falls back to Order # plus the order number.
Refund description takes the same tags. You may want to make refunds visibly distinct on a statement rather than matching the original payment.
Payment fees
You can charge a fee per payment method, set on each method individually. Two settings here control how those fees behave across all of them:
- Select tax class for fee picks the WooCommerce tax class applied to the fee line, so it's taxed the way your accountant expects rather than always at standard rate.
- Payment fee display controls whether the customer sees the fee including or excluding VAT.
The fee amounts themselves are on the payment methods page.
Whether you're allowed to charge a payment fee, and how much, depends on the payment method and on the rules that apply to your business. Making sure your setup complies with them is your responsibility.
Payment page language
Buckaroo's payment pages can follow the customer or be fixed:
| Option | Behaviour |
|---|---|
| Dynamic language | Uses the customer's browser language, falling back to English. The default, and the right choice for most stores. |
| English / Dutch / French / German | Forces every customer onto that language. |
Pick a fixed language only if you sell to one market and want the payment page to match your storefront exactly regardless of what browser your customer uses.
Verification settings
iDIN verifies a customer's identity and age through their own bank, before they pay. It's useful if you sell age-restricted products and need something stronger than a date-of-birth field the customer types in themselves.
| Setting | What it does |
|---|---|
| iDIN mode | Off, Test or Live. Off by default. |
| iDIN specific product categories | Which product categories trigger verification. |
Leave the category list empty to verify on every order. Select one or more categories to verify only when the cart contains a product from them, which is usually what you want: there's no reason to put an identity check in front of someone buying a t-shirt.
Verification happens before payment. Once a customer is verified, they're told so and can continue to checkout.
iDIN needs to be active on your Buckaroo contract, and it's a Dutch scheme, so it only applies to customers banking with a participating Dutch bank. More detail on iDIN.
Advanced settings
Debug logging is for diagnosing a problem, not for permanent use. On a busy store it fills the disk or the database quickly and captures far more request detail than you want sitting around. Switch it off when you're done.
| Setting | What it does | Default |
|---|---|---|
| Debug mode | Records detailed request and response data. | Off |
| Debug data storage | Where that data goes: File, Database or Both. | Both |
Log entries are pruned automatically after 14 days by a daily scheduled task, so the logs don't grow without limit even if debug mode is left on.
File logs are written one file per day. Both file and database entries are readable from the Reports section, described below.
Reports
Reports is a log viewer inside the admin, so you don't need server access to read what the plugin recorded. It lists entries with an error number, date and description, and lets you open or download an individual log file.
This is the first place to look when a payment behaves unexpectedly. Pair it with the transaction's status history in Buckaroo Plaza: the two together tell you which side of the connection failed. See Troubleshooting.
Updated 3 days ago