Verified evidence01
Retry-safe webhook processing
Stable payment references and duplicate checks protect settlement processing during repeated webhook delivery
Source · Public GitHub repository
NestJSWebhooksIdempotency
Project archive
Project case study · APIs
Payone ERPNext Payment Integration
NestJS integration service that validates Payone webhooks, reconciles payments, and updates ERPNext sales invoices through retry-safe processing.
NestJSTypeScriptNode.jsPayone APIERPNext REST APIsWebhooksIdempotency
2024
Read this case as a
Choose your lens
Outcome-focused delivery
Built a backend integration connecting an external payment provider with ERPNext accounting workflows, including validation, failure handling, and duplicate protection.
Evidence mode · on
Claims come with context
Each outcome shows its source, related capability, and confidence level. Missing operational data stays visibly unavailable.
Verified evidence02
ERPNext invoice integration
Successful payment events are mapped to ERPNext sales-invoice operations
Source · Public GitHub repository
ERPNext APIsTypeScript
Supporting context03
Automated reconciliation workflow
Valid payment notifications trigger the accounting update workflow without requiring the same manual entry process
Source · Operational workflow description
PaymentsAccounting automation
Skill → proof
Where each capability shows up
NestJSRetry-safe webhook processing
WebhooksRetry-safe webhook processing
IdempotencyRetry-safe webhook processing
ERPNext APIsERPNext invoice integration
TypeScriptERPNext invoice integration
PaymentsAutomated reconciliation workflow
Accounting automationAutomated reconciliation workflow
01 / Problem
A fragmented workflow slowed the whole system.
Manually recording Payone payments in ERPNext delayed invoice settlement and introduced a risk of missing or duplicated accounting updates. Webhook retries could also repeat the same financial operation if processing was not designed to be idempotent.
02 / Solution
One product model, expressed clearly at every layer.
I developed a NestJS integration service that validates Payone webhook requests, identifies the related ERPNext invoice, and applies the appropriate settlement update. Stable payment references and duplicate checks protect the accounting workflow during webhook retries.
Architecture replay
Walk through the system
Select a layer to inspect its responsibility.
Active layer 1
Payone payment gateway
Payone payment gateway owns the user-facing workflow and consumes a stable contract.
Responsibility stays explicit at this boundary.
Decision log
Make webhook processing idempotent
- Context
- Payone could retry a webhook when acknowledgment was delayed
- Decision
- Checked stable payment references before applying ERPNext mutations
- Trade-off
- Required persistence and duplicate checks but prevented repeated ledger postings
Decision log
Separate gateway validation from reconciliation
- Context
- Provider-specific security logic should not be mixed with ERPNext accounting rules
- Decision
- Divided request validation, payment interpretation, and ERPNext settlement responsibilities
- Trade-off
- Added service boundaries but improved testing and maintainability
03 / Challenges overcome
Complexity moved behind durable boundaries.
The integration needed to verify webhook authenticity, map external payment references to ERPNext records, and return acknowledgments without creating duplicate ledger changes. Failure and retry behavior had to be explicit because the workflow affected accounting records.
Next step
Want to discuss a similar system?
Share the context and we’ll find a useful first move.