The Context

When Bank Indonesia mandated the national payment standard SNAP (Standar Nasional Open API Pembayaran), all existing payment systems needed to migrate to the new protocol before the regulatory deadline.

The risk was massive: failure to comply would block tuition payments for 30,000 students, impacting an annual transaction volume exceeding 39,000+ total annual transactions for multiple institutions:

• Yayasan BPK PENABUR Jakarta
• Yayasan BPK PENABUR Tirtamarta

Because BCA only whitelisted the IP of our existing cPanel server, rewriting the system in a new environment was impossible without restarting the entire compliance process.
The migration had to be done on the existing PHP + MySQL stack — under extreme time pressure.

The Challenge

The legacy SOAP-based payment logic had critical issues:

• No idempotency → risk of double-charging during retries
• No concurrency control during peak tuition payment periods
• No standardized request/response format
• No full-chain auditability required by BI compliance

We needed to deliver a secure, RESTful, SNAP-compliant middleware without downtime, without moving infrastructure, and without breaking the regulatory audit trail.

The Solution

I led the full-stack migration, designing and implementing a SNAP-compliant payment gateway using PHP and MySQL on the existing cPanel environment.

Architecture Highlights

1. Database-Backed Idempotency Layer (SNAP Requirement)

Instead of Redis (the original plan), I implemented idempotency directly in MySQL to stay compatible with the whitelisted server.

Stored and verified SNAP-required IDs:

• External ID
• Inquiry Request ID
• Payment Request ID

Every incoming request checked these IDs before processing, ensuring that:

• Duplicate webhooks are ignored
• Retries are safe
• Payments cannot be double-posted

This solved the concurrency problem under high load.

2. Atomic Transactions & ACID Safety

I redesigned the MySQL schema and payment flow:

• Strict transaction boundaries
• Ledger-safe updates
• Consistent payment state machine

This ensured payments were financially correct, recoverable, and auditable.

3. Python Sync Service (Finance App Integration)

Although the gateway ran on PHP:

• A Python scheduler ran every 15 minutes
• Synced payment status updates to the finance app
• Ensured parents saw real-time confirmation in the re-registration/finance system

This bridged the legacy app with the modern payment gateway.

The Result

The system passed three full UAT cycles with BCA engineers, achieving:

• 100% UAT success rate
• Zero compliance violations
• 39,000+ total annual transactions
• Stable operation across peak payment seasons for three separate foundations

The migration delivered a modern, compliant, and safe payment infrastructure without changing servers, proving that robust engineering is possible even under strict constraints.