Octopus payment gateway microservice
A production-ready, multi-tenant payment gateway service with HMAC-SHA256 request signing, replay protection, merchant key rotation and webhook delivery.
- Role
- Platform & DevSecOps Engineer
- Type
- Built in my full-time job at Appnovation
- Period
- Sep 2025 to Oct 2025
At Appnovation I designed and built a production-ready payment gateway microservice that takes Octopus payment processing out of a single client project and turns it into a service several merchants and applications can share: authentication, request signing, encryption at rest, merchant management and webhook delivery with retries.
The problem
Octopus is Hong Kong's stored-value payment network. The payment logic for it lived inside one client project. A second and a third project would have meant copying security-critical code, so it needed to become a standalone service that several merchants and applications could call.
Why it was hard
- Multi-tenant: each merchant has its own credentials, keys and profile, isolated from the others.
- Every request must be authenticated and tamper-proof, and a captured request must not be replayable.
- Secrets have to be encrypted at rest, and keys have to rotate without downtime.
- Webhooks out to merchant systems must survive slow or failing endpoints.
Architecture
A Spring Boot service (Java 17) on PostgreSQL, packaged with Docker. Callers authenticate with JWT and sign each request with HMAC-SHA256. A cryptographic service handles hashing and AES-256-GCM encryption. Merchant management APIs own profiles and keys. Webhook delivery runs asynchronously, outside the request path.
- Java 17
- Spring Boot
- Spring Security
- PostgreSQL
- Docker
- JWT
- HMAC-SHA256
- AES-256-GCM
What I built
Platform & DevSecOps Engineer
- 01Designed and implemented the cryptographic service: SHA-256 hashing and AES-256-GCM encryption for secrets at rest.
- 02Built the HMAC-SHA256 request signature system with replay-attack prevention.
- 03Created merchant management APIs with key rotation and profile management.
- 04Implemented asynchronous webhook delivery with retry logic and failure handling.
- 05Wrote the unit and integration test suite.
Decisions and challenges
Sign every request and reject replays
An HMAC-SHA256 signature proves who sent a request and that it was not altered. Replay protection means a captured request cannot simply be sent again.
Rotate keys gracefully
API keys rotate automatically and the old key keeps working for a grace period, so a merchant can switch without an outage.
Deliver webhooks asynchronously
Delivery to merchant systems runs outside the payment request, with retries and failure handling, so one slow endpoint cannot hold up a payment.
Encrypt what must be stored
Secrets at rest are encrypted with AES-256-GCM, and hashing is used wherever the original value is never needed again.
Stories worth telling
Multi-tenant from the start: each merchant has its own credentials, keys and profile.
API keys rotate automatically, with a graceful expiry so merchants can switch without an outage.
Verified outcomes
- A production-ready, standalone, multi-tenant payment gateway service with merchant management APIs.
- About 3,680 lines of code delivered in two weeks, with unit and integration tests.
- Request signing, replay protection, key rotation and webhook retries implemented as shared infrastructure instead of per-project code.
Numbers
- About 3,680 lines of code in two weeks
- Multi-tenant architecture
- HMAC-SHA256 with replay protection
What this shows a client
I can design the security-critical core of a payment system (request signing, key management, encryption and reliable webhooks) as a service other teams build on.
Tell me what you are building.
A few lines are enough: what it is, where it stands today, and what you need from an engineer. The form is just below, or email me if you prefer. I reply within two working days.