Retail, marketplaces, and payment service providers — open banking routing in checkout, invoicing & payment links when you bill outside the cart.
Card networks still dominate online checkout. They stack intermediaries, push scheme fees into the 1.5–3% range, stretch settlement to T+1–T+3, and leave merchants exposed to card-not-present fraud and chargebacks. StixBNK provides open banking routing for compliant account-to-account (A2A) flows — shoppers Pay by bank with SCA at their institution — plus invoicing & payment links for hosted collection when the sale happens offline or by invoice. Webhooks, references, and reconciliation stay in one API layer.
Use case 1
Instant A2A payment at checkout
Context
Traditional e-commerce stacks depend on Visa, Mastercard, and acquirers. That implies multiple hops, blended pricing, and fraud models optimised for cards — not for high-trust bank rails.
Several intermediaries between shopper and settlement
CNP fraud, chargebacks, and dispute handling overhead
Merchant pain
Compressed margins after payment fees
Slow settlement (T+1 to T+3)
High card-not-present fraud exposure
What StixBNK enables
Direct payment initiation from the customer’s bank account via regulated open banking APIs. The payer authorises in their bank app or web session (SCA); funds move account-to-account with a clear payment reference tied to your order.
Technical flow
Checkout presents Pay by bank alongside existing methods.
StixBNK creates a payment initiation request with amount, creditor, and reference.
Customer is redirected to their bank (OAuth-style handoff + SCA).
Strong authentication — biometrics, device signing, or OTP as required by the ASPSP.
Bank confirms authorisation; status propagates to StixBNK.
Webhook notifies your OMS / ERP so you only fulfil on authorised or settled states.
Settlement can be near real-time or same-day depending on rail and geography.
Illustrative API surface
Paths below are representative; your live integration uses the endpoints and keys from your merchant dashboard.
< 10sTarget confirmation window where instant rails apply
Use case 2
Invoices & hosted payment links
Friction
Offline or B2B sales that never reach the cart
Chasing wire references and mismatched remittances
Card links that fail on high amounts or CNP risk
Approach
Issue a structured invoice in StixBNK, email the PDF with a hosted payment link, and settle via the same open banking routing used for checkout — bank SCA, webhooks, and a payer receipt.
Flow
Merchant creates and issues the invoice (buyer + lines + VAT).
StixBNK attaches a unique payment reference and checkout URL.
Customer opens the link, picks their bank, completes SCA.
Webhook marks the invoice paid; merchant and payer see confirmation.
One stackGateway API and invoices share OB routing
Faster cashA2A settlement vs. chasing bank transfers
Use case 3
One stack for gateway API and invoices
Why separate PSPs hurt
Different providers for checkout vs. “pay by link”
Split webhooks and reconciliation playbooks
Coverage gaps when markets diverge
StixBNK keeps open banking routing central: API collections and invoicing & payment links share providers, hosted checkout, and status events. Finance sees one transaction language whether the payer started in cart or from an emailed invoice.
Flow
Create a collection via merchant API or issue an invoice with a pay link.
Payer lands on hosted checkout and completes bank SCA.
Same webhook contract updates OMS / ERP / invoice status.
Optional payer receipt closes the loop.
Impact
OpsOne routing map, one sandbox, one support model
ProductShip checkout and billing without two PSP projects
API paths and KPI ranges are illustrative — not guarantees. Regulatory coverage, bank participation, and your commercial terms determine live behaviour.
