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.
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.