Payment Providers & Payment Accounts
Conceptual model for how Fangate routes buyer payments and creator payouts. This avoids exposing confidential routing tables while clarifying terminology.
Definitions
| Term | Meaning |
|---|---|
| Payment provider | The PSP / integration type—for example Stripe, PayPal, Epoch, or another supported processor. It describes which family of APIs and contracts Fangate uses. |
| Payment account | A specific configured account under a provider—e.g. a particular merchant ID, connected account, or processor profile used for a subset of traffic or configuration. |
One provider can have multiple payment accounts (different currencies, regions, products, or rollout stages). Fangate may route transactions using configuration (database-driven rules) rather than a single hardcoded path.
Why this matters for integrators
- Buyer checkout and creator payouts can depend on which provider and account apply to a transaction. This is server-side logic.
- Public API clients (mobile app, partner integrations) should not assume a fixed mapping from “user country” → “exact PSP” unless explicitly documented for a given endpoint.
- Do not build branching logic on internal IDs of payment accounts unless the API exposes them for your integration—and even then, treat them as opaque.
What a buyer sees at the checkout
The checkout of a product offers up to three tiles. A creator can hide any of them, account-wide or per product — see Payment options. Hiding a tile only hides it; the payment method itself stays on.
| Tile | What it offers |
|---|---|
| PayPal | Payment with a PayPal account. |
| Credit Card / Other | Cards, plus the local payment options listed below. |
| Crypto | Payment in cryptocurrency, with the creator's crypto discount when one is set. |
Local payment options behind “Credit Card / Other”
Which of these a buyer is offered depends on the buyer's country and on the provider handling the transaction:
| Payment option | Available in |
|---|---|
| BLIK | Poland |
| Boleto Bancário | Brazil |
| EPS | Austria |
| Euteller | Finland |
| Multibanco | Portugal |
| Paysera | Lithuania |
| paysafecard | Australia, Austria, Belgium, Brazil, Canada, Chile, Croatia, Cyprus, Czech Republic, Denmark, France, Germany, Greece, Ireland, Italy, Kuwait, Liechtenstein, Luxembourg, Mexico, Netherlands, New Zealand, Norway, Poland, Portugal, Romania, Saudi Arabia, Slovakia, Slovenia, Spain, Sweden, Switzerland, United Kingdom |
| PIX | Brazil |
| Przelewy24 | Poland |
Treat this list as the current state, not as a contract: the provider can change it without an API version bump, and a client should not branch on it.
Confidentiality
Exact routing rules (which account is chosen for which currency, risk score, or A/B test) are operational detail and may change without a breaking API version bump. Integrations should rely on:
- Documented checkout and wallet behaviors,
- Webhooks where provided for payment state,
- Support for edge cases.