Network retries can create duplicate payments. Idempotency keys prevent this. This guide explains how to use them in the Bekena API correctly.
When you make an API request to create a payment, your network call might fail mid-flight. Your code retries. Did the first request succeed and create a payment, or did it fail? Without idempotency keys, you might create two identical payments for the same order.
What is an Idempotency Key?
An idempotency key is a unique string you include in your API request. If you make the same request twice with the same idempotency key, the API treats it as a single request and returns the same response. The second call doesn't create a second payment — it returns the result of the first call.
How to Use Idempotency Keys with Bekena
Rules for Idempotency Keys
- ✓Must be unique per operation — not per API key or per session
- ✓Use a deterministic key based on your business data (order ID + user ID)
- ✓Keys are valid for 24 hours — after that, the same key may create a new resource
- ✓Never reuse a key for a different operation (e.g., don't use the same key for two different orders)
- ✓Keys are case-sensitive strings up to 255 characters
Idempotency in Webhook Handlers
Bekena may deliver the same webhook event multiple times due to network issues or retries. Your webhook handler must also be idempotent. Use the payment ID from the event as a key to check if you've already processed this specific payment.
Testing Idempotency
In the Bekena sandbox, you can test idempotency by making the same API call twice with the same Idempotency-Key header and verifying you receive the same payment object both times. Check that only one payment record was created in the Bekena dashboard — you should see one entry, not two.