Payments Engineering in Practice: Double Charges, Money Types and Webhooks

Payments engineering means moving money correctly through systems you do not control: idempotency keys, integer money, server-side prices, verified webhooks, reconciliation and an audit trail. RAITHub has shipped this inside TheSkinProof and Sundor Skin and built a fintech dashboard for a client. It has not shipped a regulated fintech product such as lending, custody or card issuing.

This guide covers the patterns, the payment code behind them, where compliance begins and engineering ends, and when you should hire someone else. If you are looking for a team to build payment flows into your product, the service page is FinTech and payments engineering.

What payments engineering has RAITHub actually shipped?

Payment flows inside two live commerce platforms, and a payments abstraction designed into a third. None of them is a licensed financial product.

Platform we built	Payments and money engineering	Status and scale
TheSkinProof	bKash, Nagad, SSLCommerz and cash on delivery. Cash-on-delivery orders are risk-assessed before they are accepted. Pricing is server-authoritative. Per-variant inventory is decremented inside the order transaction.	Live since Q2 2025. 217 API endpoints, 750+ automated tests.
Sundor Skin	Credit limits and payment terms enforced in the database. Amounts stored as integer poisha, never floats. Staff-verified bKash and Nagad receipts. Transactions retry on serialisation conflicts. A hash-chained audit log.	Deployed September 2026. 146 tables, 530+ automated tests, including a 21-case IDOR security suite.
PadhAI	Designed for 9 payment gateways under one abstraction.	A platform in our portfolio, described on the work page.

TheSkinProof is the founder's own marketplace, built and run by RAITHub. RAITHub has also built a fintech dashboard for a client; that is fintech software, but not a licensed or regulated financial product, so it does not change what follows. RAITHub has not built lending, custody, card issuing, money transmission or core banking, and it says so on the first call.

What does payments engineering inside a product involve?

It means moving money correctly through a system you do not fully control. Your server, the payment provider, the customer's bank or wallet and the network between them can each fail, retry or reply late.

A payment path has seven parts, and each needs its own design decision: pricing, initiation, confirmation, fulfilment, refunds, reconciliation and audit. The rest of this page is about getting the money right at each one.

How do you prevent double charges and duplicate orders?

Use idempotency keys on every write that moves money, unique constraints in the database, and a state machine that only allows valid transitions. Any one of these alone leaves a gap.

An idempotency key is a unique value the client sends with a request. The server stores the key with the result. If the same request arrives again, because a user double-tapped or a mobile network retried, the server returns the stored result instead of charging again. The full explanation is in what is idempotency in API design.

The database is the second line of defence. A unique constraint on the provider's transaction ID means a confirmation delivered twice cannot create two payment records, even if application code has a bug. The third line is the order state machine: an order can move from pending to paid, but a second "paid" event on a paid order is recorded and ignored.

Concurrency is the quieter risk. Two requests can read the same credit balance at the same moment and both decide there is room. On Sundor Skin, transactions retry on serialisation conflicts, so the database, not luck, decides which write wins. Idempotent write paths are a standard part of RAITHub's Backend & API service, described on the services page.

Why should money never be stored as a floating-point number?

Binary floating-point numbers cannot represent most decimal amounts exactly, so small rounding errors appear and accumulate. Store money as integer minor units, or as a fixed-precision decimal type.

In JavaScript, and in any language using standard double-precision floats, 0.1 + 0.2 evaluates to 0.30000000000000004. One such error is invisible. Thousands of them, summed across invoices, discounts and tax, produce a ledger that does not balance. Sundor Skin stores every amount as integer poisha (one taka is 100 poisha), so arithmetic is exact and rounding happens only where a rule says it should.

How money is stored	When it fits	Risk
Floating-point number	Never, for money	Silent rounding errors that compound
Integer minor units (cents, poisha)	Most payment and invoicing systems	Needs a currency code beside every amount
Fixed-precision decimal (for example PostgreSQL NUMERIC)	Interest rates, FX rates, fractional unit prices	Rounding rules must still be defined in one place

Why must prices be calculated on the server?

Because anything the browser or app sends can be edited. The client says what the customer wants; the server decides what it costs.

TheSkinProof uses server-authoritative pricing: at checkout the server recalculates the total from its own data and ignores any price the client claims. Stock follows the same rule. Per-variant inventory is decremented inside the same database transaction that creates the order, so two customers cannot both buy the last unit.

How should payment webhooks and redirects be handled?

Treat the redirect back from a payment page as a hint, not proof. Confirm payment with a verified server-to-server call or a signed webhook, record each event idempotently, and process it asynchronously.

• Verify the source. Check the provider's signature, or query its API, before trusting any payload.
• Store first, act second. Save the raw event under a unique provider ID, acknowledge quickly, then process it in a background job.
• Expect disorder. Events arrive late, twice or out of order. The state machine decides what each one may change.
• Have a fallback. If a confirmation never arrives, a scheduled job asks the provider for the status.

More detail is in what webhooks are and how to build them and idempotency in API design.

How do you handle cash on delivery and manual wallet receipts?

Treat them as payment methods with their own risk and verification rules, not as exceptions handled by hand. They are common in markets where cards are not the default.

On TheSkinProof, cash-on-delivery orders are risk-assessed before they are accepted, because a refused delivery still costs money. On Sundor Skin, trade buyers pay by bKash or Nagad, staff verify the receipts, and each buyer's credit limit and terms are enforced in the database. Enforcing a limit in the database, not only in application code, means no screen, script or future feature can approve an order that breaks it.

How do reconciliation and audit trails work?

Reconciliation regularly compares your records with the provider's settlement reports and flags every difference. An audit trail records who changed what and when, in a form that cannot be quietly edited.

Reconciliation needs a settlement import, matching rules (provider transaction ID first, then amount and date), and an exceptions queue that a named person reviews. Differences are normal: fees, partial refunds, chargebacks and timing. The goal is that every difference has an explanation.

For the audit trail, Sundor Skin uses an append-only, hash-chained audit log. Each entry includes a hash of the one before it, so deleting or editing a past entry breaks the chain and can be detected.

How does PCI DSS apply to a startup taking card payments?

PCI DSS applies to entities that store, process or transmit cardholder data, or that could affect its security. The main way to reduce your scope is a provider's hosted checkout or hosted fields, so card numbers never touch your servers.

The standard is published by the PCI Security Standards Council; version 4.x is current. With hosted fields or a hosted payment page, the card number goes from the customer's browser straight to the provider, and your systems see only a token. Scope shrinks, but obligations remain: you still protect the page that loads the payment form and complete whichever assessment applies. Your acquirer or a Qualified Security Assessor (QSA) confirms which one that is.

If your plan involves storing raw card numbers, talk to a QSA before writing code.

What about KYC and AML?

Know-your-customer (KYC) and anti-money-laundering (AML) obligations depend on your jurisdiction, your licence and what your product does. Engineering implements them; a compliance professional defines them.

Most products integrate a specialist identity-verification provider rather than building verification in-house. The engineering sits around that provider: verification states, retries, manual review queues, re-verification triggers, record retention and an audit trail for each decision. The platforms described above do not run a regulated KYC or AML programme.

Not legal or compliance advice. This page describes engineering practice in general terms. Whether PCI DSS, KYC, AML or licensing rules apply to you, and how, is a question for a qualified compliance partner, a QSA and your lawyers in each market you serve.

What should you test in payment code?

The failures that cost money: repeated requests, events in the wrong order, two writes at once, rounding, and payments that never confirm. Each deserves a named test that runs on every change.

Failure	Test that proves it is handled	Design decision behind it
A request is sent twice	Replay the same idempotency key; assert one charge and one order	Idempotency keys and a unique constraint on the provider transaction ID
Webhooks arrive late, twice or out of order	Deliver "paid" before "pending", and "paid" twice; assert the final state	A payment state machine that decides what each event may change
Two writes read the same balance	Run concurrent orders against one credit limit; assert the limit holds	Serialisable transactions with retry, or row locks
Rounding drifts	Sum many small amounts with discounts and tax; assert the ledger balances	Integer minor units and one rounding rule
A payment never confirms	Drop the webhook; assert the scheduled status check resolves it	A fallback job and a stuck-payment runbook

Specify the money types, the state machine and the reconciliation design before code, and have your compliance partner review the scope at the same point. RAITHub's phases are in how RAITHub delivers software, the testing method in how RAITHub tests, and how quotes work on the pricing page.

What it costs to build payments into a product in 2026

Published 2026 guides put one payment gateway integration at $5,000–$20,000, PCI DSS implementation at $15,000–$50,000, and a digital wallet or payment app MVP at $40,000–$100,000. Those are market figures, not RAITHub quotes. RAITHub publishes no rates; it gives a written fixed-scope estimate after a free 15-minute technical audit.

Payments estimates move on lines that ordinary feature work does not have:

• Provider onboarding and certification. Most payment providers require merchant onboarding before live keys are issued, and some review or certify your integration first. That is calendar time you cannot compress, and every rail you add goes through it again.
• How card data flows. Hosted checkout or hosted fields keep card numbers off your servers and shrink your PCI DSS scope. Handling raw card data moves the project into a different price band and a formal assessment.
• Number of rails and markets. Each gateway or wallet is its own integration, webhook handler, refund path and reconciliation import. TheSkinProof runs 4 rails; PadhAI was designed for 9 behind one abstraction.
• Reconciliation. Settlement imports, matching rules and an exceptions queue per provider, so every difference between your ledger and theirs has an explanation.
• Identity verification. KYC providers charge per verification, on top of the engineering for verification states, review queues and retention.
• Licensing. If the product itself is regulated, such as lending or money transmission, legal and licensing work sits outside any engineering estimate, and usually on the critical path.

Scope	Typical market range (2026)	What drives it
One payment gateway integration	$5,000–$20,000, plus per-transaction fees	Provider API, signed webhooks, refunds, onboarding and go-live review
Open banking API integration	$10,000–$30,000, plus monthly licensing	Bank connections, consent flows, data normalisation
PCI DSS implementation	$15,000–$50,000, plus annual recertification	How much of your system touches card data
Digital wallet or payment app MVP	$40,000–$100,000	Rails, balances, ledger, identity verification
Lending platform MVP	$50,000–$120,000	Underwriting rules, repayment schedules, licensing. RAITHub has not built one.
Neobank app MVP	$60,000–$150,000	Banking-partner integration, cards, compliance programme. RAITHub has not built one.

Figures are from Saigon Technology's September 2026 fintech cost breakdown, which gives a timeline of 8–12 months for a wallet or payment app. Its ranges often more than double from the low end to the high end, so treat them as orders of magnitude, not as a budget.

RAITHub quotes the engineering it can stand behind: the payment integrations, money types, state machine, reconciliation and tests, each as a separate line with written assumptions. Compliance review, assessments and licensing are yours to budget with your compliance partner, and the estimate says so.

Why RAITHub for payments engineering

For one kind of project: payments inside a product, such as marketplace checkout, SaaS billing, rent collection or trade credit, where the product itself is not a licensed financial service. RAITHub is a founder-led software studio, founded in 2024 in Dhaka, Bangladesh, working with clients worldwide.

• Payment code running in production. TheSkinProof, the founder's own marketplace, takes bKash, Nagad, SSLCommerz and cash on delivery with server-authoritative pricing and 750+ automated tests.
• Money modelled correctly. Sundor Skin stores amounts as integer poisha, enforces credit limits in the database, retries on serialisation conflicts and keeps a hash-chained audit log, under 530+ automated tests.
• Stripe inside a SaaS product. PropDesk collects rent through Stripe, tied to each lease.
• Fintech software for a client. RAITHub has built a fintech dashboard for a client. It is not a regulated or licensed product, and RAITHub does not present it as one.
• Two ways to engage. A fixed-scope build, or a dedicated team for ongoing work. You own the code through a present-assignment IP clause.

When RAITHub isn't the right fit

Hire a specialist fintech firm if you need proven regulated fintech delivery today, a certified vendor, or a team to interpret regulation for you. Look for one that has taken a comparable product through licensing and a regulator's or auditor's review, and ask to speak to that client.

• You need regulated fintech delivery experience now. If you are building lending, custody, card issuing, money transmission or a bank, and your investors or regulator expect a vendor who has shipped one, RAITHub is not that vendor yet.
• You need a SOC 2 or ISO 27001 certified vendor. RAITHub is not certified; see the security page.
• You plan to store raw card data. A card vault is specialist, heavily assessed work. Use a provider's tokenisation, or hire a team that has taken such a system through assessment.
• You have no compliance partner. RAITHub engineers to requirements; it does not decide what regulation requires of your business.
• You want the lowest hourly rate with no tests. A CI-gated test suite is part of every engagement, and payment code is the last place to drop it.

How do you start a payments project with RAITHub?

The FinTech and payments service page sets out what RAITHub builds and what it does not. To talk it through, book the free 15-minute technical audit. An NDA is signed before any detailed discussion.

Bring three things: the payment methods and markets you need, what happens to the money after it is collected, and who your compliance adviser is, if you have one.

Last reviewed: 28 September 2026.

Frequently asked questions

Has RAITHub built a regulated fintech product?

No. RAITHub has not shipped lending, custody, card issuing or another regulated fintech product. It has built a fintech dashboard for a client, and shipped payments engineering inside two live commerce platforms, TheSkinProof and Sundor Skin.

Which payment methods has RAITHub integrated?

TheSkinProof takes bKash, Nagad, SSLCommerz and cash on delivery. Sundor Skin records staff-verified bKash and Nagad receipts against database-enforced credit limits. PadhAI was designed for 9 payment gateways under one abstraction.

How do you stop a customer being charged twice?

Combine idempotency keys on payment requests, a unique database constraint on the provider's transaction ID, and an order state machine that ignores repeated confirmations. Each layer catches what the others miss.

Should money be stored as floats or integers?

Never floats. Store integer minor units, such as cents or poisha, with a currency code, or use a fixed-precision decimal type. Sundor Skin stores every amount as integer poisha.

Does a hosted checkout make me PCI DSS compliant?

Not by itself, but it can greatly reduce your scope, because card numbers never reach your servers. You still have obligations and an assessment to complete. Confirm yours with your acquirer or a QSA.

Can RAITHub handle KYC and AML?

RAITHub can engineer the integration with an identity-verification provider, including states, review queues and audit trails. What your KYC and AML programme must contain depends on your jurisdiction and licence, and a compliance professional should define it.

How much does it cost to add payments to an app?

Saigon Technology's September 2026 breakdown puts one payment gateway integration at $5,000–$20,000 plus per-transaction fees, and PCI DSS implementation at $15,000–$50,000 if your systems handle card data. These are market figures; RAITHub gives a written fixed-scope estimate after a free 15-minute audit.

What should payment code be tested for?

Duplicate requests, webhooks that arrive late, twice or out of order, concurrent writes against one balance, rounding drift, and payments that never confirm. Each needs a named test that runs in CI on every change.