> For the complete documentation index, see [llms.txt](https://support.swisspay.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://support.swisspay.ai/reference/integrations.md).

# Payment processors

SwissPay routes card and alternative-payment traffic through one or more processor connections. From your application's perspective the API surface is identical -- the same `POST /api/v1/payments` and webhook events apply -- and the underlying processor is selected per-merchant during onboarding.

## Card acquiring

Card payments today are settled through **Adyen for Platforms** using their Server-to-Server Checkout API. What this means in practice:

* Card data submitted to `POST /api/v1/payments` is tokenised by the processor; SwissPay only stores brand, BIN and last 4 digits.
* 3-D Secure 2 is supported end-to-end, including frictionless flows and challenge redirects (see [Payments -- 3-D Secure](/api-reference/payments.md#example--3-d-secure-automatic)).
* Saved cards are minted into stored payment methods on first charge when you opt in -- pass `save_payment_method: true` with an attached customer on the initial payment, then charge that card again later via `stored_payment_method` plus a `recurring_processing_model` (`card_on_file`, `subscription`, or `unscheduled_card_on_file`). See [Saving and reusing cards](/api-reference/payments.md#saving-and-reusing-cards).
* Disputes (chargebacks) raised against card payments are normalised into SwissPay's [provider-neutral dispute model](/api-reference/disputes.md).

## Address fields and fraud signal

The `billing_address` and `delivery_address` you submit on a [customer](/api-reference/customers.md) -- or inline on a [payment](/api-reference/payments.md) -- are forwarded to the upstream risk engine. Two practical rules govern when they actually contribute fraud signal:

* **US and Canada addresses must include `state`.** If you submit a `US` or `CA` address without `state`, SwissPay drops the entire address object from the upstream risk evaluation for that transaction rather than send a partial address the processor would reject. The payment itself still goes through, but it forgoes the address-based fraud signal. `state` should be a valid ISO 3166-2 subdivision code (for example `CA` or `NY` for the US, `ON` or `QC` for Canada). Addresses for countries that do not require a state field (for example `CH`) are unaffected.
* **Provide `line2` whenever you have it.** SwissPay derives the upstream house-number field from `line2` when present. For US and Canada addresses submitted without `line2`, a placeholder is used so the address still validates; this weakens AVS house-number matching on those specific transactions. Outside the US and Canada, the placeholder has no effect on fraud scoring.

The address is also a fraud signal in its own right: a mismatch between `billing_address` and `delivery_address` lets the risk engine reason about ship-to-bill divergence, so passing both when they differ is recommended.

## Alternative payment methods

**PayPal Managed Path** is on the SwissPay roadmap. Once available, PayPal will appear as a payment method on `POST /api/v1/payments`, with the same response shape and webhook semantics as cards. Public documentation will be updated when it ships.

## Why this matters for integrators

You should never need to special-case a processor. SwissPay exposes:

* One payment endpoint, one Payment object, one webhook event family.
* One dispute model regardless of where the dispute originated.
* One saved-card / token concept usable across providers.

If you find yourself branching on a processor name in your code, that is almost certainly something we should normalise -- please tell us at <support@swisspay.ai>.