Central payment hub
The order and the payment have to match. To the cent.
Your store sends the signed cart. We recalculate every line against the central catalogue, and only then open a payment page — on the provider, under our domain. A one-cent difference stops the payment before it starts.
| Wool overcoat | 2 × | 99.50 | 199.00 |
| Standard shipping | 1 × | 50.00 | 50.00 |
| Your store says | 249.00 | ||
|---|---|---|---|
| We recalculate | 249.00 | ||
Link valid 15 minutes, once.
No order, no payment page.
The flow
Four steps between the cart and the bank
Nothing is embedded in your store, and no card detail ever reaches a page we render.
Signed cart arrives
At checkout the plugin signs the order with your store’s secret and posts the SKUs, quantities, line totals and the order total.
Every line is recalculated
Central unit price × quantity, line by line, then the total. Unknown SKU, inactive mapping, wrong quantity or a one-cent gap is refused here — before an order exists.
One-time link
The hub answers with a single-use URL that lives 15 minutes. It opens at top level, never in an iframe, and can be used once.
Hosted payment
The customer is redirected to the provider’s own payment page. The result returns as a signed, idempotent notification and lands in the payment desk.
Price integrity
What we check, and what we refuse
Prices are never trusted from the browser, and the accepted figures are frozen into the order the moment it is created.
Checked on every request
- Signature and timestamp of the sending store
- SKU and mapping against the central catalogue
- Unit price × quantity for each line
- Shipping, surcharge and discount as separate signed lines
- The order total, exactly as the store calculated it
Refused before an order exists
- A difference of one cent in any line or total
- An unknown, inactive or unmapped SKU
- A return URL that does not belong to the registered store
- The same order id with a different cart
- Rounding, nearest-price lookup, free-amount fallback — none exist
Integrations
One credential per store
Payment methods are selected on our page, so your store keeps a single key whatever the customer chooses.
WooCommerce
Install the plugin, paste the key and secret, done. Blocks and classic checkout are both supported.
JTL-Shop
Payment method plugin with a central appearance profile and update reporting.
Any other platform
Your developer posts the same signed order and receives a payment link. Documentation on request.
Payment desk
Every payment, with the numbers behind it
Reconciliation
Customer gross, settlement gross, provider fee, exchange rate and net balance, each kept in its own currency. CSV export per store and date range.
Refunds and disputes
Refunds issued from the desk, disputes tracked with their evidence deadline, order status moved only by verified provider events.
Connected stores
Keys issued, disabled or rotated per store. Heartbeat shows whether the plugin is alive, delayed or offline.
Audit
Append-only activity log: who changed a price, who rotated a key, which request was refused and why.
Security
What never happens here
- No card number, CVC or wallet token touches our pages — payment runs on the provider’s hosted page
- No iframe, no embedded form, no copy of the provider’s UI
- Store secrets are encrypted at rest; a rotated secret is shown once
- Requests and responses are signed in both directions
- Provider notifications are verified and processed once
- Accepted prices are frozen in immutable order lines; editing the catalogue later cannot change an issued invoice
Connect a store
Send the platform, the domain and the currency you sell in. We issue the credential and the plugin.