Softech designed and implemented a stablecoin payment layer for an NDA-protected B2B client. Instead of moving product logic into an external gateway, the architecture separates responsibilities: the application remains the source of truth for amount, order and business status, CoinGate provides checkout and the payment rail, while an internal ledger, idempotent webhooks and reconciliation create an auditable path from payment intent to settlement. The model uses managed crypto infrastructure without making a single provider the source of truth for the core product.
Business context and the situation before implementation
The client operated a B2B product with conventional order and invoice settlement, while a segment of customers expected stablecoin payments. The priority was to add USDC without rebuilding the entire payment domain or creating a proprietary custody or exchange layer.
- USDC was introduced as an alternative rail for existing obligations rather than a separate commerce system.
- The invoice or order had to remain the authoritative business document regardless of payment method.
- Finance operations needed a clear relationship between provider order, transaction and settlement.
- The product could not treat a single webhook delivery as sufficient authority for payment state.
Before state
Before implementation, the product had no payment-intent model prepared for blockchain payments. Adding a gateway link alone would leave gaps in state handling, errors, refunds and reconciliation, especially because provider events are asynchronous and can be delivered repeatedly.
- No unified state between the business document and external payment.
- No deterministic protection against crediting a repeated callback twice.
- No shared audit trail across order, payment and settlement.
- Exceptions would require manual comparison across several systems.
Goals, success criteria and constraints
Discovery started from the obligation lifecycle rather than the provider API. We mapped when the amount due is created, who owns state, when payment can be considered complete, and what evidence operations and finance need to see.
Product goals
- Add USDC as a controlled payment method inside the existing product.
- Keep price and business obligation outside the blockchain rail.
- Design idempotent processing for callbacks and status changes.
- Create an internal payment ledger independent of provider balance.
- Provide reconciliation from invoice or order through settlement.
Success criteria
- Every CoinGate order maps unambiguously to an internal payment intent.
- A repeated callback cannot apply payment business effects twice.
- Product state can be reconstructed from stored events and authoritative provider data.
- Refunds preserve history by creating auditable follow-up events.
- An operator can trace the full payment chain without accessing application code.
NDA and disclosure minimisation
Client identity, volumes, commercial terms and internal system names are not published.
External payment rail
Checkout, conversion and part of settlement remain provider responsibilities, so the product must correctly handle asynchronous status changes.
Existing invoice and order domain
The new rail cannot change how the product identifies an obligation and its owner.
Operational recoverability
The system must recover correct state after callback interruption, network failure or manual intervention.
Analysis and product decisions
- We separated the business amount from the crypto amount presented at checkout.
- We defined the payment intent as the contract between the business domain and payment rail.
- We introduced internal statuses independent of provider naming.
- We defined idempotency, retry and manual reconciliation rules.
- We designed an audit trail for payment, refund and settlement events.
Solution architecture
The architecture combines the product domain, payment orchestration service, CoinGate integration, internal ledger, reconciliation and operational audit processes. Each layer has an explicitly separated responsibility.
- 01Layer 01
Product and business document
Invoice, order or account defines who pays, what is being paid for and which value remains the source of truth.
Orders / invoicesBusiness domain - 02Layer 02
Payment intent
A stable identifier connects the business document with a payment attempt, source currency, expiry and state.
Payment state machineIdempotency keys - 03Layer 03
CoinGate integration
The adapter creates provider orders, redirects customers to checkout, receives callbacks and can re-fetch authoritative provider state.
CoinGate APIHosted checkoutCallbacks - 04Layer 04
Internal ledger
The ledger records accepted payment events, business effects and state history without overwriting the past.
Event historyRelational ledger - 05Layer 05
Reconciliation and operations
The operations layer compares payment intent, provider order, settlement and any refund, surfacing discrepancies for review.
ReconciliationAudit loggingOperations UI
Problems, decisions and implemented capabilities
A callback could be delivered more than once.
Every event received an idempotency key and guarded state transition.
Idempotent webhook processing
Repeated delivery does not credit the payment or trigger the business workflow twice.
Provider statuses did not map one-to-one to product domain states.
We defined an internal state machine and explicit provider-to-product mapping.
Provider-independent payment state
Changing provider does not require rewriting every downstream business workflow.
Finance needed traceability from invoice to settlement.
We connected document, payment intent, provider order and settlement identifiers in one audit trail.
End-to-end reconciliation
Discrepancies can be investigated per obligation without manually guessing relationships.
A refund could obscure the history of the original payment.
A refund is treated as a follow-up event linked to the original payment.
Auditable refunds
History remains complete and preserves both the original credit and later value reversal.
A callback outage cannot leave payment permanently stuck in an intermediate state.
We added authoritative state re-fetch and manual reconciliation capability.
Recoverable payment processing
State can be repaired without manually editing business-domain data.
Technology decisions
| Technology | Role | Rationale | Trade-off |
|---|---|---|---|
| CoinGate API | External payment rail | It delegates crypto checkout and payment processing to a dedicated provider while keeping product orchestration inside the client application. | The integration depends on the external provider API contract and status lifecycle. |
| Hosted checkout | Payer interface | It reduces the product scope for address, network and payment-screen handling while allowing the provider to present currently supported options. | Part of the user experience is hosted outside the main application. |
| Payment state machine | Domain state | It separates transient provider state from product business effects and controls allowed transitions. | It requires explicit mapping between provider and internal statuses. |
| Internal ledger | Audit and financial effects | It preserves operational history and independence from the external provider dashboard and balance. | It adds a dedicated data layer that must be reconciled. |
| Reconciliation jobs | Consistency control | They detect missed callbacks, status divergence and settlement discrepancies without relying only on the online path. | Repair jobs must be safe to run repeatedly. |
Integrations and data flows
CoinGate Orders API
Product → CoinGateCreate a provider order linked to the internal payment intent and business document.
Every order uses a stable internal identifier and can be re-fetched.
CoinGate callbacks
CoinGate → backendAsynchronous payment status notification triggers validation and a controlled state transition.
The callback is treated as a verification trigger rather than the only source of truth.
Settlement / finance export
Ledger → financeExpose reconciled payment, refund and settlement data to finance operations.
Exports are based on accepted ledger state and surface unresolved exceptions.
AI, security and reliability
Idempotency
Callbacks, retries and reconciliation must remain safe when the same operation is executed more than once.
Provider data verification
The system does not trust the user redirect alone; backend verifies identifier, amount and current provider state.
Audit trail
Every material state change records its reason, source and relationship to the business document.
Recoverability
A missed callback or temporary integration outage can be recovered through reconciliation without manual data edits.
Separation of concerns
Provider credentials, domain logic and settlement information have separated responsibilities and access scope.
Implementation, testing and release
- 1Phase 1 / Discovery
Map the obligation lifecycle and responsibility boundaries between product and provider.
- Payment intent and state ownership model
- Provider-to-product status mapping
- Exception and refund scenarios
Result: A domain contract was established independently of checkout implementation details.
- 2Phase 2 / Provider integration
Connect order creation, hosted checkout and callback processing to the payment orchestration service.
- CoinGate API adapter
- Callback verification and idempotency
- Order-to-payment-intent identifier mapping
Result: Stablecoin payment became part of the existing order lifecycle.
- 3Phase 3 / Ledger and reconciliation
Build durable event history and payment-to-settlement reconciliation.
- Internal ledger
- Reconciliation jobs
- Operator audit view
Result: Operations gained one place to inspect state and discrepancies.
- 4Phase 4 / Release hardening
Test failure, retry, refund and delayed-status scenarios before production use.
- Repeated-callback tests
- Expired and delayed payment tests
- Manual reconciliation runbook
Result: The system was prepared for conditions beyond the ideal checkout path.
Repeated callbacks
Tests verify that repeated delivery of the same event does not duplicate business effects.
Intermediate and delayed states
Scenarios cover awaiting, confirming, delayed and later reconciled payment states.
Refund and reversal
Refunds follow their own lifecycle and do not remove the original payment history.
Reconciliation recovery
A controlled test removes or delays an online event and the reconciliation process restores correct state.
What confirms the project description
Because of the NDA and the absence of approval to publish volumes, we do not present percentage KPIs or transaction values. Outcomes are evaluated through confirmed system properties: lifecycle consistency, recoverability, idempotency, auditability and reconciliation capability.
| Scope | Basis | Reference | Confirmation | Interpretation boundary |
|---|---|---|---|---|
| The product and payment provider are separated by an internal payment intent and integration adapter. | Architecture diagram | CG-01 · project material and implementation architecture | Operationally confirmed | The diagram is anonymized and does not expose internal client service names. |
| Business payment state is maintained independently of CoinGate status naming. | State model | CG-02 · project material and implementation architecture | Operationally confirmed | The public version simplifies the number of internal states and transition guards. |
| Callbacks are processed idempotently before business effects are applied. | State model | CG-02 · project material and implementation architecture | Operationally confirmed | Specific idempotency keys and database schema are not published. |
| Reconciliation links payment intent, provider order and settlement into one operational trace. | Reconciliation diagram | CG-03 · project material and implementation architecture | Operationally confirmed | Bank details, client identifiers and job frequency remain confidential. |
| A refund preserves its relationship to the original payment rather than overwriting history. | State model | CG-02 · project material and implementation architecture | Operationally confirmed | The diagram shows the pattern rather than the client exact status names. |
| The operations layer supports discrepancy analysis without direct edits to domain data. | Reconciliation diagram | CG-03 · project material and implementation architecture | Operationally confirmed | The operator UI is not published because of the NDA. |
How to read this information
- Payment counts and USDC volume are not published.
- Settlement values and provider commercial terms are not published.
- Sales growth is not attributed solely to the addition of a new payment rail.
- All published outcomes describe system capability and architecture rather than estimated marketing KPIs.
Process change, decision consequences and lessons
| Area | Before | After | Business impact |
|---|---|---|---|
| Payment model | External payment had no dedicated domain contract. | A payment intent connects the business obligation with a specific payment attempt. | State is unambiguous and recoverable. |
| Callbacks | A single event could directly mutate order state. | Webhook delivery goes through verification, idempotency and guarded state transition. | Retries do not create duplicate effects. |
| Ledger | Payment history would be split between the domain and provider dashboard. | An internal ledger stores accepted events and relationships. | The team owns an auditable payment record. |
| Settlement | Settlement would require manual matching across identifiers. | Reconciliation links order, payment, refund and settlement. | Discrepancies become visible and operationally manageable. |
| Provider dependency | Business logic could become coupled to one gateway status model. | An adapter translates provider events into a provider-neutral product model. | Architecture reduces the future cost of changing the payment rail. |
CoinGate hosted checkout
- Alternative
- Custom crypto checkout
- Trade-off
- Less visual control in exchange for a smaller scope around addresses, networks and payment UX.
- Rationale
- For this model, delivery speed and delegation of the payment rail mattered more than full control of the payment screen.
Internal ledger
- Alternative
- Use provider balance and order history as source of truth
- Trade-off
- An additional data layer increases implementation scope.
- Rationale
- It provides independence, auditability and recoverability of business effects.
Provider-neutral domain states
- Alternative
- Propagate CoinGate statuses through the application
- Trade-off
- Requires mapping and maintaining an internal state machine.
- Rationale
- It protects the product core from provider changes and semantic differences.
Out-of-band reconciliation
- Alternative
- Rely only on webhooks
- Trade-off
- Adds periodic processes and operational tooling.
- Rationale
- It restores state after missed events or integration outages.
Key lessons learned
- Design the obligation lifecycle before choosing provider endpoints.
- Hosted checkout does not remove the need for the product to own an auditable payment state.
- Idempotency is a domain requirement, not merely a webhook implementation detail.
- Reconciliation should be designed from the first version rather than added as an emergency tool later.
- The provider should remain a replaceable payment rail when business logic does not require tight coupling to its model.
Which organisations this model is relevant for
SaaS with international customers
When some customers want to settle invoices in stablecoins while the company does not want to build its own custody and payment processing.
B2B invoicing
When crypto is an alternative rail for settling an existing business obligation.
Commerce and digital platforms
When checkout needs crypto while orders, fulfilment and accounting remain in the conventional backend.
Products requiring faster launch
When a managed provider reduces implementation scope without giving up ownership of product payment state.
Related expertise and services
CoinGate Integration
BOFU path for CoinGate orders, hosted checkout, callbacks, ledger and reconciliation.
Crypto & Stablecoin Payment Systems
Softech service covering managed gateways and custom on-chain payment infrastructure.
Digital Assets & Blockchain
Capability hub for payments, wallets, smart contracts and token engineering.
Smart Contract Development
Related capability for systems requiring programmable settlement or on-chain logic.
Custom wallet payment infrastructure
The second payment model: dedicated addresses, blockchain observation, ledger and treasury.
API Engineering
Backend integration and API contracts used in payment orchestration.
Web Application Development
Application and operations-panel development around payment workflows.
Want to add USDC without building your own payment processor?
We can design the payment intent, provider integration, webhooks, ledger, reconciliation and operations so stablecoin becomes another payment rail rather than a separate technology silo.
Key confirmed facts
The following statements summarise the confirmed product scope and contain no unapproved growth data.
- 1
The client project is protected by an NDA and the organization name is not published.
- 2
The implementation uses CoinGate as the external payment rail.
- 3
USDC is the payment asset described in the published case-study architecture.
- 4
The product owns an internal payment intent linked to the business document.
- 5
Callbacks are handled idempotently before business effects are applied.
- 6
The internal ledger is independent from provider balance and dashboard.
- 7
Reconciliation links payment intent, provider order and settlement.
- 8
Refunds are recorded as events related to the original payment.
- 9
The architecture separates domain states from provider status naming.
- 10
Volumes, settlement values and percentage KPIs are not published.
Visual evidence
The diagrams present confirmed product scope and workflows described in this material. They are not mock-ups or claims of undocumented outcomes.
FAQ
Why did we keep payment logic outside CoinGate?
The provider is the payment rail, while invoice, order, entitlement and business status belong to the product. An internal payment intent and ledger prevent the application from depending on a single callback or provider dashboard.
What happens when a webhook is delivered more than once?
Every event is handled idempotently. Re-delivery of the same callback cannot credit the payment twice or trigger downstream workflows a second time.
Can the provider settle the payment into fiat?
The architecture supports provider-managed settlement. The product layer preserves its own payment state and reconciliation data independently of the settlement currency chosen with the provider.
How are refunds handled?
A refund is a separate workflow linked to the original payment intent. The system does not overwrite payment history; it records a new event and its relationship to the original settlement.
Does the case study disclose client information?
No. The client name, volumes, commercial terms and operational data are excluded. We describe the architecture pattern and technical scope that can be disclosed without breaching the NDA.
