Idempotency on every order
A retry never creates a second charge.
Our own cores
QR payments platform via API
One API to collect via QR, whatever the bank.
.NETPostgreSQLAngularPrimeNG
The challenge
Several applications needed to collect via interbank QR. Each bank exposes a different API, confirmations arrive asynchronously and reconciliation was done by checking transactions by hand. Integrating every system directly with every bank multiplied the work and the risk.
How we solved it
We built a multi-tenant platform that offers a stable API contract. Behind it, one adapter per bank translates that contract. Client systems only create orders and receive signed notifications; they never talk to the bank.
Architecture
How it is built.
Simplified view of the components and how information flows.
01
Client systems
ERP or online store
Mobile app
02
Public API
Idempotent orders
API keys per app
03
Core
Worker & reconciliation
Signed webhooks
04
Banks
Bank A adapter
Bank B adapter
.NETPostgreSQLAngularPrimeNGWebhooksDockerCaddyOpenAPI
Technical decisions
Why we built it this way.
One adapter per bank
Adding or switching banks does not affect systems already integrated.
Separate services
Public API, admin, bank callbacks and worker scale and fail independently.
Signed webhooks with retries
Client systems can verify the source and never miss confirmations.
Encrypted bank credentials
Each company’s secrets are stored encrypted and every action is audited.
Outcome
What changed.
- Integrating a new system means consuming a documented API with a test collection.
- Every payment is fully traceable: order, QR, confirmation and notification.
- Automatic backups, health checks and a VPS deployment guide.
Ready to build what’s next?
Let’s find the right solution for your business.
Tell us about your goals and one of our engineers will get back to you personally.