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).
• Saved cards are minted into stored payment methods on first charge when you opt in (storePaymentMethod: true + shopperReference), then reused on subsequent payments without resubmitting card details.
• Disputes (chargebacks) raised against card payments are normalised into SwissPay's provider-neutral dispute model.

Address fields and fraud signal

The billing_address and delivery_address you submit on a customer -- or inline on a payment -- 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.