Dalil - Bilingual Developer Portal for a Saudi Payments API

Console home, apps, app detail, sandbox data and request logs. Each of the 9 demo apps, 7 sandbox and 2 production, opens its own detail page with credentials, redirect URIs, scopes, webhooks and activity tabs.

A client secret is shown in full only when it is generated and then kept as its last 4 characters. Up to two can be active, so a rotation needs no downtime, and a third is blocked until one is revoked.

Reject the next consent, fail the next payment with a chosen error, delay webhooks or make the test bank unavailable. Testing them counts toward the go-live technical checklist.

6 personas with English and Arabic names, 26 accounts on test IBANs with the reserved bank code 99, 156 transactions and 18 consents, plus 30 request logs and 5,127 sandbox calls over 7 days.

Credentials Sent by Hand

Sandbox secrets were created by a support engineer and sent in chat. Production uses OAuth 2.0 with signed client authentication and certificate-bound tokens over mutual TLS, so secrets, public keys and certificates each need their own safe flow.

A Sandbox That Never Fails

Developers need realistic customers, accounts and consents to build against, but no real customer or IBAN may ever appear. They also need to see consent rejections, failed payments and unavailable banks before they meet them in production.

Debugging Without Customer Data

Sandbox calls can be shown in full to help a developer debug, but production request bodies carry customer data. Personal data under the PDPL has to stay minimal and in the Kingdom.

Going Live Through Compliance

Each production applicant is checked as a business customer: commercial registration, VAT, national address, authorised signatory, beneficial owners and sanctions and PEP screening under the Saudi Anti-Money Laundering Law. That check ran on email and spreadsheets.