Balady–AlRajhi BNPL Integration

The problem

Citizens want to spread payments for higher-value Balady services (e.g. permit fees, infringement settlements). Integrating with a Buy-Now-Pay-Later provider opens two attack surfaces simultaneously:

1. Webhook ingest — the bank pushes payment-status events into Balady’s network. Anyone who can forge a request could maliciously mark a debt as paid.
2. Presigned redirect URLs — citizens are sent off-domain to complete the BNPL flow. A leaked URL can be replayed by an attacker.

The architecture

Multi-provider design — Alrajhi is the first integrated bank but the contract is generic, so additional providers slot in without rework.

Signed-webhook security stack at Apigee:

1. HMAC-SHA256 signature verification against the shared secret
2. IP allow-list restricting traffic to the bank’s known egress ranges
3. Replay protection via a sliding-window nonce store
4. Idempotency keys — a webhook seen twice has no double effect

Encrypted single-use presigned URLs with double-validation:

• The URL is signed AND encrypted, so its contents (citizen-id, amount, reference) cannot be inspected or modified
• Validated once at the Unified Payment Page (front side) AND once at the callback (back side) — both validations must agree

Runtime

ASP.NET Core (3+ replicas), Redis (3 master + 3 replica HA for the nonce store), RabbitMQ for the asynchronous integration with the Billing System. Four canonical integration flows: BNPL eligibility, BNPL request, webhook status update, status query.

Outcome

A defensible BNPL surface for the Balady estate. The webhook security stack is now the template for any other bank that joins the Unified Payment Page.