> For the complete documentation index, see [llms.txt](https://help.alternativepayments.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.alternativepayments.io/payments-and-invoicing/payments-and-payouts/reversed-after-success.md).

# Reversed-After-Success Payments

**A payment marked "reversed after success" initially went through — money moved — and was then pulled back by the bank or payment processor. This article explains what that status means, how it differs from a standard decline, what you and your customers will see, and how to recover.**

***

## What "reversed after success" means

When a payment is reversed after success, two things happened in sequence:

1. The payment was authorized and settled. Funds moved.
2. After settlement, the bank or Adyen pulled the funds back.

This is different from a payment that never completed. The money reached its destination and was subsequently reversed — which is why the status and messaging are distinct from a standard decline.

***

## How this differs from a standard decline

A standard decline happens before money moves. The payment is rejected at authorization and no funds are transferred.

A reversal after success happens after funds have already moved. Because the sequence of events is different, the failure code is different too. Alternative Payments uses dedicated failure codes for reversed-after-success payments — separate codes for both card and ACH — rather than reusing the equivalent decline code. This ensures the status you see accurately reflects what actually happened.

Previously, a race between two competing signals could allow a generic placeholder reason to win over the specific one. Classification now comes from a single, reliable signal per payment, so the correct code is applied consistently.

***

## What you and your customers will see

Because the situation is materially different from a decline, the messaging is written specifically for it. Both partner-facing and customer-facing copy describe what actually happened — that the payment succeeded and was later reversed by the bank — rather than reusing decline wording that would be misleading once money has already moved.

***

## Recovering from a reversal

### Card payments

For card reversals, the underlying payment method may need to be reviewed or replaced before attempting another charge. If you are unsure of the cause, contact your Alternative Payments Customer Success Manager or reach out via Live Chat in your partner dashboard.

### ACH payments

For ACH reversals, you do not need to escalate before taking action. Partners are able to self-serve ACH reversal recovery by requesting a new payment method from their customer. Once the customer provides a new bank account, you can add it to their profile and retry the payment.

For steps on adding a new payment method to a customer's profile, see [Customer Payment Methods](/payments-and-invoicing/payments-methods/customer-payment-methods.md).

***

## A note on balance-platform notifications

Not all reversal events carry a specific reason code. Events that arrive through the balance-platform accounting notification channel are excluded from the dedicated failure-code logic, because Adyen does not provide a reason code through that channel. For those events, a generic message is expected. This is normal behavior and does not indicate a problem with classification.

***

## Related articles

* [Customer Payment Methods](/payments-and-invoicing/payments-methods/customer-payment-methods.md)
* [ACH Chargebacks](/payments-and-invoicing/payments-and-payouts/ach-chargebacks.md)
* [Refund Management](/payments-and-invoicing/payments-and-payouts/refund-management.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://help.alternativepayments.io/payments-and-invoicing/payments-and-payouts/reversed-after-success.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.