A payment API connects order, payment and status. This article does not publish MulenPay endpoints, fields or SDKs; those must come from official documentation.
Event flow
create order
create payment
show checkout
receive webhook
verify event
update order status
Success page is not the source of truth
The customer may close the page or return before the event. Server-side status confirmation should update the order.
Idempotency
A repeated click should not create duplicate payments. Store operation keys and check existing payment state.
Webhook reliability
| Event | Check | Action |
|---|---|---|
| webhook received | signature and order ID | update order |
| event repeated | idempotency | do not duplicate |
| unknown status | event log | escalate |
Common integration errors
| Error | How it shows up | What to do |
|---|---|---|
| duplicate payment | customer pays twice for one order | store an operation key, check for an existing payment |
| lost webhook | order stays unpaid after a charge | poll the operation status instead of waiting for the event |
| invalid signature | events arrive but are rejected | verify the secret and signing algorithm against the docs |
| status mismatch | your system and the dashboard disagree | treat the server-side operation status as the source of truth |
Testing
Before production, test success, decline, retry and refund with a demo payment. Discuss integration through contacts.
If you need a payment API for a website, app or CRM, take a look at the MulenPay payment API page.
FAQ
Why are webhooks needed?
They provide server-side status events.
What is idempotency?
Protection against duplicate operations after repeated requests.
Why is the success page not enough?
It depends on customer behavior and does not guarantee final status.
Is the pseudocode API documentation?
No. Real parameters must come from official documentation.
