> For the complete documentation index, see [llms.txt](https://docs.reachplatform.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.reachplatform.com/faqs/payments/payment-gateway-faq.md).

# Payment Gateway FAQ

Stripe vs IPPAY behavior, routing, and refund rules when switching gateways.

### Quick answers

<details>

<summary>Do we need our own Stripe or IPPAY account?</summary>

No.

* Stripe uses Reach-owned Stripe accounts and credentials.
* IPPAY runs under the existing Reach MID.

</details>

<details>

<summary>Which gateway is used by default?</summary>

Reach natively supports both payment gateways as default, and clients have the option to choose from both.

</details>

<details>

<summary>Will existing customers be moved to new payment gateway automatically?</summary>

No. There is no forced migration of saved payment methods.

Customers move to new payment gateway naturally when they add a new payment method.

</details>

<details>

<summary>If we change gateways, what happens to refunds and credits?</summary>

Refunds and credits always run on the **original gateway** and **original payment method**.

This remains true even if that gateway is disabled for new payments.

</details>

### Gateways

<details>

<summary>Which gateways does Reach support today?</summary>

Reach supports:

* **Stripe**
* **IPPAY**

</details>

<details>

<summary>Can we use a gateway other than Stripe or IPPAY?</summary>

Not today. Additional gateways are on the roadmap.

Share requirements and timelines with your Account Manager.

</details>

### Configuration and routing

<details>

<summary>How is gateway configuration managed?</summary>

Gateway settings are configured per brand (tenant).

This controls:

* which gateways are enabled
* the default gateway for new transactions
* which payment methods are available
* whether customers can choose a gateway at checkout (if enabled)

</details>

<details>

<summary>Can we enable multiple gateways at the same time?</summary>

Yes. A tenant can have multiple gateways enabled.

Reach can still route based on customer context and saved methods.

</details>

<details>

<summary>What are common routing scenarios?</summary>

* New customer makes a first payment: **New default payment gateway**
* Existing customer has a saved card: **Old payment gateway**
* Existing customer adds a new card: **New default payment gateway**
* Refund for a transaction made on an older saved card: **Old payment gateway**
* Refund for a new transaction: **New default payment gateway**
* ACH Direct Debit for new setups: **New default payment gateway**

</details>

{% hint style="warning" %}
Don’t disable a gateway expecting refunds to “move”. Refunds must reconcile to the original processor.
{% endhint %}

### Payment methods

<details>

<summary>What payment methods are supported?</summary>

* Credit and debit cards (default)
* ACH Direct Debit (optional, enabled per tenant)

Both methods are supported on Stripe and IPPAY.

</details>

<details>

<summary>Is autopay required?</summary>

Yes. Customers must keep a payment method on file for automatic billing.

The payment method on file is charged on the bill date.

</details>

<details>

<summary>Can customers store more than one payment method?</summary>

Yes. Customers can:

* add a secondary card
* change the default method

Reach stores tokens only. Reach does not store raw card data.

</details>

<details>

<summary>How does ACH Direct Debit work in Reach?</summary>

ACH is optional and enabled per tenant.

ACH enablement usually involves extra operational decisions. Bring it up early during onboarding.

</details>

<details>

<summary>What safeguards exist for ACH confirmation delays?</summary>

ACH confirmation can be delayed. Reach supports controls to reduce fulfillment risk:

* Delayed fulfillment (optional delay before service is provisioned)
* Provisional service (allow service while confirmation is pending)
* Failure protocols (failed ACH follows the same retry and suspension logic as card failures)
* Permission-based overrides (agent overrides with audit logging)

</details>

### Declines, retries, and customer experience

<details>

<summary>Will customers see gateway-specific messaging or branding?</summary>

No. Payment routing is designed to be invisible to end customers.

* No forced migration of saved cards or bank details.
* No gateway-specific branding on web or app.
* Consistent handling of soft and hard declines.

</details>

<details>

<summary>What happens when a payment fails?</summary>

Reach automatically retries common declines.

Default behavior:

* retry on **Day 0**
* retry on **Day 1**
* then follow the brand’s configured dunning schedule

</details>

<details>

<summary>Which decline codes are common?</summary>

Examples:

* `530` (Do Not Honor): issuer declined without a reason
* `302` (Credit Floor): customer is over their credit limit
* `521` (Insufficient Funds): insufficient account balance

</details>

### Reporting, descriptors, and controls

<details>

<summary>How do we identify which gateway processed a transaction in reports?</summary>

Payment reports include `Payment_Gateway_Name` per transaction.

</details>

<details>

<summary>Which reports are commonly impacted by gateway differences?</summary>

Common examples:

* Daily Payments
* Monthly Refunds

</details>

<details>

<summary>What statement descriptors are supported?</summary>

* **Static descriptor:** fixed brand name for every transaction
* **Dynamic descriptor:** can include transaction-level or order-level detail

</details>

<details>

<summary>Are payment configuration changes tracked?</summary>

Yes. Reach audit logs:

* gateway and payment-method configuration changes
* agent payment actions in Reach Central

Permissioned access controls limit who can change payment behavior.

</details>

<details>

<summary>Who owns PCI compliance?</summary>

The gateway providers (Stripe or IPPAY) handle payment processing and PCI scope.

Reach manages the integrations and platform-level controls.

</details>


---

# 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 dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.reachplatform.com/faqs/payments/payment-gateway-faq.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

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.