Русский
Українська
Հայերեն
ქართული
Қазақша
Español
Français
Deutsch
Italiano
فارسی
Article focus
Create a receipt after verified payment
A customer return URL is not proof that a payment is final.
The fiscal workflow must begin only after the backend verifies the provider status and checks the amount, currency and order reference. Triggering a receipt from a browser redirect can create an incorrect record when a customer closes a tab or a provider reports a delayed result.
The payment event and fiscal task need stable identifiers. This makes it possible to prove which successful payment led to which receipt and to prevent duplicate issuance when callbacks are repeated.
- Verify the payment on the server.
- Store payment and fiscal job identifiers.
- Keep receipt status separate from payment status.
Run fiscalization asynchronously and visibly
Receipt delivery can fail independently from a successful payment.
A fiscal service may be temporarily unavailable while the payment provider has already confirmed a transaction. An asynchronous queue keeps the confirmed payment intact and retries the fiscal task under controlled rules rather than blocking the customer journey.
Operations need a clear view of queued, completed and failed fiscal tasks. The dashboard should show the original payment, retry count, error category and permitted next action without exposing credentials or raw sensitive data.
- Use idempotent fiscal jobs.
- Apply bounded retries and alerting.
- Provide a reviewed manual recovery path.
Model refunds and exceptions explicitly
A failed receipt, a refund and a duplicate callback are different events.
When a receipt fails after payment, do not reverse the payment status automatically. The business needs a traceable exception state and a procedure based on current fiscal requirements and the merchant configuration.
Refunds are separate business events with their own authorization, audit and fiscal consequences. The exact fiscal and tax treatment must be checked against the current legal and provider rules before publication or implementation.
- Do not create a second receipt on retry.
- Audit every manual resolution.
- Review current regulatory requirements before go-live.
FAQ
Can a receipt be created synchronously in a payment webhook?
It is safer to enqueue an idempotent fiscal task after verification so a slow or failed fiscal service does not corrupt the payment flow.
What if payment succeeds but receipt creation fails?
Keep the verified payment, record a fiscal exception and retry or review it through a controlled operational workflow.
How are duplicate callbacks prevented from creating duplicate receipts?
Link the fiscal job to the verified payment with a unique idempotency key and enforce state-transition rules.
