Building payment gateways
Write a payment-gateway extension: the manifest, the stateless driver contract, the settlement rule, capabilities, credentials, testing, publishing and the trust model.
A payment gateway extension is code only — one PHP driver plus a salieno.json manifest — that starts a payment, verifies the money over a webhook, and refunds it. The driver never credits balance itself.
Build a minimal but working payment-gateway extension from scratch — two files, a hosted checkout redirect and a signed webhook — then grow it capability by capability.
Every field in a payment gateway's salieno.json manifest, key by key — the schema Core validates, the capabilities that gate the UI, and the credentials that render the Auto Gateways config form.
Every method your payment-gateway driver implements, with the exact array shape Core reads back — process, ipn, refund, testConnection — and the one settlement rule a driver must never break.
A gateway's declared capabilities decide which controls Core draws — at checkout, in the admin refund modal, and for automatic renewals. Declare one to show it; omit it and Core routes around it.
A gateway's driver and its config are separate — declare credential fields in the manifest, read them per call from the encrypted config, solve the webhook-has-no-Deposit problem with ownConfig(), and verify it all with a Test connection probe.
Unit-test your stateless gateway driver against canned API and webhook payloads without touching the network: prove capability honesty, minor-unit correctness, a fail-closed signing secret, and that you settle through Core's boundary — never in the driver.
Package a gateway driver as a signed marketplace extension, get it approved, and ship updates that never lose a saved key or re-charge the operator.
A gateway moves real money with the operator's processor credentials, so Core enforces trust rather than assuming it — the signing scheme, hardened install, the three-gate load, and the payment rule to verify or fail closed.