> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://ixopay.ferndocs.com/developer-hub/documentation/reference/integration/processing-options/server-to-server/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://ixopay.ferndocs.com/_mcp/server.

# Server-to-server

Server-to-server processing is a payment option that allows merchants to perform transactions and interact with the payment system without involving the end-user directly. It is commonly used for various scenarios such as recurring payments, refunds, de-registering payment methods, capturing or voiding previous preauthorizations, and SEPA DirectDebit transactions.

## Use cases

* [Recurring payments](https://documentation.ixopay.com/docs/guides/getting-started/recurring-payments)
* [Refunds](https://documentation.ixopay.com/docs/guides/payments/refunds)
* [De-registering](https://documentation.ixopay.com/docs/guides/payments/saving#deleting-saved-payment-information) payment methods
* [Capture](https://documentation.ixopay.com/api/transaction/capture) or [void](https://documentation.ixopay.com/api/transaction/void) of a previous [preauthorization](https://documentation.ixopay.com/api/transaction/preauthorize)
* SEPA DirectDebit transactions (subject to legal jurisdiction)

## Processing flow

1. The transaction is triggered, for example by a customer using a stored credit card.
2. 

Merchant

The merchant sends the appropriate API call —for example a [debit](https://documentation.ixopay.com/api/transaction/debit) or [refund](https://documentation.ixopay.com/api/transaction/refund) request— to the IXOPAY platform.
3\. The IXOPAY platform processes the request and sends a transaction request to the PSP.
4\. The PSP processes the transaction and sends the result back to IXOPAY platform.
5\. 

Merchant

The IXOPAY platform processes the PSP's response and, using the `callbackUrl` field, notifies the merchant via a callback to the URL provided in the initial API call. This callback includes the payment status and any relevant details.
6\. 

Merchant

The merchant handles the callback, it is recommended to store the transaction's `uuid` for future use.
7\. 

Merchant

The merchant responds to the callback with:

Callback response

```http
HTTP/1.1 200 OK
Content-Type: text/plain

OK
```

8. The IXOPAY platform responds to the merchant backend with a request containing the status of the transaction, usually `FINISHED`, `PENDING` or `ERROR`.
9. 

Merchant

The merchant decides what page to display to the customer depending on the transaction status.

Here's a visual representation of the processing flow using a sequence diagram:

```mermaid
%%{ init: { "sequence": {"mirrorActors": false} } }%%
sequenceDiagram
  accTitle: Sequence diagram for server-to-server processing
  accDescr: A visual representation of the steps listed above.
  autonumber
  actor C as Customer
  participant M as Merchant
  participant G as IXOPAY platform
  participant PSP

  C-->>+M: Trigger, for example a purchase with card-on-file
  M->>+G: (Recurring) debit, or refund, etc.
  G-->>+PSP: Transaction
  PSP-->>-G: Result
  par
    G-)+M: Callback to callback URL
    M->>M: Store result
    M->>-G: OK
  end
  G-->>-M: Result
  M->>-C: Thank-you or error page
```