Skip to main content

Idempotency

Every public mutable operation should receive Idempotency-Key. In MuPag it protects you from double clicks, network retries, client timeouts and accidental worker replays.

How to generate it​

  • Use UUID v4, ULID or a stable business-event hash.
  • Reuse the same key only for the same semantic intent.
  • If the payload changes, generate a new key.

Where to apply it​

  • POST /v1/charges
  • POST /v1/customers
  • POST /v1/products
  • POST /v1/products/{productId}/plans
  • POST /v1/coupons
  • POST /v1/checkout-sessions
  • POST /v1/subscriptions

What to persist​

Store the key, the canonical payload and your business identifier. That makes 409 Conflict easy to reconcile with the original successful request.

Did this page unblock the next step?

Feedback stays inside the docs flow and should never include customer or card data.

mupag / support

How can we help?

Quick answers, AI and our team.

Frequently asked questions

How do I start integrating?

Follow the quickstart, configure the QA environment and create your first test charge.

Read documentation
My PIX payment is pending. What now?

Confirmation is asynchronous. Check the charge status and webhook events before fulfilling the order.

Read documentation
How do I receive payment notifications?

Register a webhook endpoint, verify its signature and handle duplicate events safely.

Read documentation
How do subscriptions work?

Read the subscriptions guide to configure recurring billing and follow the charge lifecycle.

Read documentation
Where can I find authentication help?

See how to use environment credentials in the documentation. Never share your key in chat.

Read documentation