# Send a new payment once the fault clears

[Retry a payment](https://devportal.qa.winkpg.io/docs/decide/retry-a-payment.md): Whether a payment that didn't go through is worth sending again, and the request that sends it again without charging the customer twice.

Nothing was decided and no funds were held. The payment simply didn't happen.

**Your answers so far**

- What came back from the payment? A failure. The platform couldn't complete the request.

**What to build**

Don't route a failure through your decline handling. Once the fault has cleared, create the payment again under a new idempotency key. Don't rely on the Retry operation here: it's seldom offered on a failure, so read the transaction's allowedActions list rather than assuming.

**Worth knowing**

- A new attempt needs a new idempotency key. A create that got an answer is replayed under its key for 48 hours, so resending with the old one hands you the same refused transaction.
- A failure arrives as Transaction.Failed, not Transaction.Declined. Subscribe to both if your systems react to refused payments.
- Where the merchant has more than one processor, the platform may already have failed over before you saw the result.

**Where to go next**

- [Understanding declines and rejections](https://devportal.qa.winkpg.io/docs/guides/understanding-declines-and-rejections.md)
- [Processor routing and failover](https://devportal.qa.winkpg.io/docs/guides/processor-routing-and-failover.md)
- [Retry a payment without a double charge](https://devportal.qa.winkpg.io/docs/blueprints/retry-a-payment-safely.md)

- [Start over](https://devportal.qa.winkpg.io/docs/decide/retry-a-payment.md): go back to the first question.

## See also

- [All documentation](https://devportal.qa.winkpg.io/llms.txt): the machine-readable index of every public page on this site.