Most payment integrations do not stall on code. They stall on sequence: underwriting must finish before keys are issued, and keys before anything can be tested, so a developer ready in week one is still waiting in week five.
BazPay inverts that order. A sandbox account needs no card, test keys are issued the moment a merchant signs up, and a 3-D Secure 2 authorisation can be pushed through hosted fields the same afternoon. Underwriting runs alongside the build rather than in front of it; live keys switch on when it completes. The published BazPay median is one day for hosted checkout, three days for a CMS plugin, ten days for a direct REST integration.
What the three days consist of
- Pull test keys. No card, no sales call, no procurement step in between.
- Drop in hosted fields. Card inputs are served and tokenised by BazPay, so the PAN never touches the merchant’s servers or logs.
- Push a test authorisation. The BazPay sandbox ships 3-D Secure 2 test cards plus SEPA Instant, Bancontact and Przelewy24 simulators.
- Wire the webhook. Signed BazPay webhooks replay from the event log, so retry and reconciliation logic is testable rather than hoped for.
- Install the plugin, if there is a CMS. The WooCommerce, Magento 2, PrestaShop and Shopware plugins call the same endpoints a custom build would — see integrations.
Nothing about the fast path is a stripped-down tier. The charge is scored against the merchant’s own history, routed to the connection most likely to approve it, and re-presented if the first returns a soft decline. Every settled transaction is itemised interchange++, with interchange, scheme fee and the BazPay margin on separate lines from the first capture.
Why the scope decision comes before the styling decision
The choice that quietly determines a merchant’s compliance year is not the checkout design but who serves the fields that capture card data. If every element touching cardholder data is delivered by the validated provider, the merchant stays on SAQ A; a script collecting card data inside the merchant’s own DOM moves them to SAQ A-EP — a far longer self-assessment plus quarterly ASV scanning. PCI DSS v4.0.1 sharpened this: requirements 6.4.3 and 11.6.1 moved out of SAQ A, while SAQ A-EP still carries both. BazPay will state its scope position in writing for a QSA, naming the pattern actually deployed rather than the one that was sold.
Vaulting happens inside the BazPay cardholder data environment in Dublin and Sydney, and tokens are registered with the schemes’ network tokenisation services, so a reissued card keeps billing without a new card form. Tokens are portable: if a merchant leaves, BazPay exports the vault to the next provider under a scheme-approved migration.
The result is a build validated before a contract is signed. Underwriting questions on category, coverage and settlement currency run in parallel, and BazPay answers borderline models with a written risk position instead of a monitoring letter ninety days later. Those questions go to the team here.
