# Payment providers > Every built-in payment provider - what it offers, which fields it needs, where its credentials come from, and how to test it. Source: CBX documentation, version 4.0 preview (unreleased). Canonical page: https://docs.configbox.at/docs/4.0-preview/admin-guide/commerce/payment-providers. Last updated 2026-08-15. --- > **Audience:** store admins · **Scope:** the built-in providers on the payment method form · **Last reviewed:** 2026-08-15 **What this covers** — Each payment provider CBX ships with: which markets and payment types it serves, the fields its settings block asks for, where to get the credentials, and how to test it before going live. Set up the method itself first — see [Set up payment methods](https://docs.configbox.at/docs/4.0-preview/admin-guide/commerce/set-up-payment-methods). ## How providers work in general - **Pick the provider on the payment method form**; its settings appear right below the choice. Required fields carry a marker; the status note under them turns green when the provider is ready. A method whose provider is not ready is never offered at checkout. - **The customer pays on the provider's own page** (or, for Stripe's on-site mode, in fields the provider renders into your page). Card data never touches your store — that is what keeps you out of card-security certification scope. - **Every provider has a test mode.** Keep it on while trying things out: payments run against the provider's sandbox with test cards, and the payment records are marked as test. Switch to live only after a full test round trip. - **Secrets stay secret.** API keys are stored encrypted and never displayed again — a filled field shows "a value is stored". Blank keeps it, typing replaces it. - **Webhooks** are the provider calling your store the moment money moves. Providers that need the webhook address registered in their dashboard show the exact URL as a note among their settings; copy it over. Providers without that note handle it automatically. Either way the store also re-checks pending payments on its own, so a missed call never loses a payment. ## DemoPay (test provider) The built-in fake provider. It moves no money, needs no account, and can simulate every checkout experience — hosted page, on-site card fields, wallet button, vouchers, even payment confirmations that arrive late. Use it to try the whole order flow end to end, demo the store, or train staff. The card number decides the outcome on its fake payment page (for example a card ending in 0002 declines). - Fields: **Flow to simulate**, **Shared webhook secret** (any random string), and a note that DemoPay never moves real money. ## Stripe Cards, wallets and many local methods across the US, Canada and Europe. Two ways to present it: the hosted Stripe page, or Stripe's card fields rendered inside your checkout. - Fields: **Secret key** (required), Publishable key (needed for the on-site mode), Webhook signing secret, Input mode. - Credentials: dashboard.stripe.com → Developers → API keys. Test keys start with `sk_test_`. - Webhook: register the URL shown in the settings note at Stripe → Developers → Webhooks; the signing secret it gives you goes into the Webhook signing secret field. ## PayPal The most widely recognized wallet in the US and Europe. - Fields: **Client ID** (required), **Client secret** (required), test mode. - Credentials: developer.paypal.com → Apps & Credentials → create a REST app. Sandbox and live are separate apps with separate credentials. ## Mollie One account covering the common European methods — iDEAL, Bancontact, EPS, cards and more. Which methods appear on Mollie's payment page is chosen in your Mollie dashboard, not in CBX. - Fields: **API key** (required), test mode. - Credentials: my.mollie.com → Developers → API keys. The test key starts with `test_` and works without business verification. ## Klarna Pay now, pay later and financing, strongest in German-speaking and Nordic markets. Klarna decides which of its products the customer sees, based on your merchant agreement. - Fields: **API username** (required), **API password** (required), Region, test mode. - Credentials: the Klarna merchant portal issues the API username/password pair; "playground" credentials are the test ones. ## Authorize.net The long-established US and Canada card gateway. - Fields: **API login ID** (required), **Transaction key** (required), Signature key, mode. - Credentials: the Authorize.net merchant interface → Account → API Credentials & Keys. A free sandbox account is available at developer.authorize.net. - Webhook: register the URL from the settings note under Account → Webhooks, and store the signature key so the calls can be verified. Without it, the store still confirms payments by re-checking, just a little later. ## Square Popular with US small and mid-size merchants; the customer pays on a Square-hosted page. - Fields: **Access token** (required), **Location ID** (required), Webhook signature key, mode. - Credentials: developer.squareup.com → your app → sandbox or production access token, and the location the payments should book to. - Webhook: subscribe the URL from the settings note in the Square developer dashboard; the subscription shows the signature key. The registered URL must match the note exactly. ## Adyen The enterprise-grade European provider with global card and local-method coverage; the customer pays on Adyen's hosted checkout page. - Fields: **API key** (required), **Merchant account** (required), Webhook HMAC key, Live URL prefix (live mode only), test mode. - Credentials: the Adyen Customer Area → Developers → API credentials. The merchant account is the account code payments run through. - Webhook: create a "standard webhook" in the Customer Area with the URL from the settings note; it issues the HMAC key. Going live additionally needs the live URL prefix shown in the Customer Area. ## Saferpay (Worldline) The incumbent gateway in Switzerland, France, Germany and Benelux. - Fields: **Customer ID** (required), **Terminal ID** (required), **JSON API username** (required), **JSON API password** (required), mode. - Credentials: the Saferpay Backoffice shows customer and terminal id; create a "JSON API user" there for the username/password. A self-serve sandbox exists at test.saferpay.com. ## PostFinance Checkout Switzerland's house solution: PostFinance Card, TWINT, e-finance and cards on one hosted page. - Fields: **Space ID** (required), **Application user ID** (required), **Authentication key** (required), mode. - Credentials: sign up at checkout.postfinance.ch; every account includes a test space. Create an application user with access to the space — it shows its authentication key once, at creation. - Webhook: add a webhook for transactions in the space settings using the URL from the settings note. ## Nexi Checkout The Nexi/Nets group's hosted checkout, covering Italy and the Nordics. - Fields: **Secret key** (required), **Terms URL** (required — a link to your store's payment terms page, which their checkout displays), Webhook secret, test mode. - Credentials: the Nexi group portal issues separate test and live secret keys. - Webhook: optional — invent a random string as the webhook secret and the store registers the notification automatically with each payment. ## PayU Poland's leading provider and a CEE staple: BLIK, Polish bank transfers and cards. - Fields: **POS ID** (required), **OAuth client secret** (required), Second key (MD5), mode. - Credentials: the PayU merchant panel shows all three per point of sale; a self-serve sandbox is available. - The second key verifies PayU's payment notifications — store it, or confirmations rely on re-checking alone. ## Trustly Direct bank payments (open banking), strongest in Scandinavia and growing across Europe. No cards involved — the customer pays straight from their bank account. - Fields: **Username** (required), Password, **Merchant private key** (required), **Trustly public key** (required), test mode. - Credentials: no self-serve signup — Trustly's integration team provides test credentials and exchanges security keys with you during merchant onboarding. ## Bank transfer (Swiss QR-bill) Not an online provider: the thank-you page shows your account details, a structured payment reference and the official Swiss QR code the customer can scan in their banking app. You mark the payment as settled when it appears on your bank statement — see [Track payments](https://docs.configbox.at/docs/4.0-preview/admin-guide/orders/track-payments). - Fields: **IBAN** (required), **Account holder** (required), street, postal code and city, country code.