Payment Gateways
How payment gateways connect into SGEN — store transactions and billing-related flows.
Payment gateways in SGEN are the connected providers that handle store transactions on the customer side of an SGEN-built site. The platform exposes a consistent integration surface for connecting one or more payment providers, routing checkout transactions through them, and surfacing transaction state in the admin Store Management. This page is the Reference definition of the payment-gateway integration — what the connection covers, where transactions land, and what the dependency posture looks like.
What is this for?
Read this page when you want the structural definition of the payment-gateway integration in SGEN — what role it plays in store flow, where transactions surface, and what the operator should expect when the connection is healthy versus unhealthy.
Good use cases
- You are scoping a new SGEN store and need to know how payment providers connect.
- You are explaining to a stakeholder how SGEN handles connected payment processing.
- You hit a "checkout is failing" question and want the connection model laid out.
- You are designing internal SOPs around payment-related incident response.
What NOT to use this for
- Step-by-step provider connection procedures — open the relevant Guide.
- Per-provider product documentation — that lives with the provider.
- Account-level SGEN billing (subscriptions, invoices for SGEN itself) — that lives in SG-Dashboard Billing.
- Per-release shipped behavior change — open What's New or Changelog.
How this connects to other features
- Integrations Overview — parent Reference area.
- Email and SMTP — sibling integration covering outbound communication including order confirmations.
- SG-Admin Overview — where Store Management modules (Products, Orders, Coupons) live.
- SG-Dashboard Overview — account-tier surface where SGEN-side subscription billing is administered (separate from store transactions).
Definition
A payment gateway in SGEN is a connected payment-processing provider. The integration handles the transaction flow — checkout submission, authorization, capture, refund — for store operations the customer runs through the SGEN site.
The defining property is direction. Payment gateways carry transaction events between the visitor's checkout submission and the provider's authorization layer; the provider holds the funds and the platform records the transaction state.
Purpose
The purpose of this page is to define the payment-gateway integration as a Reference layer. It explains the connection model, where transaction state surfaces, what the dependency posture looks like, and how the integration pairs with the admin Store Management pillar.
Scope
This page covers the payment-gateway integration at the Reference level.
The page covers:
- The connection model for payment providers.
- Where transaction state surfaces inside SGEN.
- The dependency posture (healthy vs unhealthy).
- The boundary against per-provider documentation and SGEN-side subscription billing.
- Per-provider product detail — provider documentation.
- Per-step setup procedures — Guides.
- SGEN-side subscription billing — covered by SG-Dashboard Billing.
Connection model
Payment gateways connect into SGEN through the platform's standard integration surface. The connection is per-site (each site can be paired with one or more payment providers).
Per-site provider pairing
Each SGEN site can be paired with one or more payment providers. The pairing happens in the per-site Store Management settings. Multiple providers can be enabled simultaneously to give checkout flexibility.
Authentication and credential handling
Provider credentials are encrypted at rest. The operator does not see credentials in plaintext after entry. The platform re-uses the connection per transaction without re-prompting.
Site · Store Management · Payment gateways
Connected providers
Card payments · live mode
Bank transfer · live mode
Wallet · not connected
Where transactions surface
Transaction state surfaces inside the admin Store Management.
Orders module
The Orders module shows every transaction the connected gateways processed, with status (authorized, captured, refunded, failed), amount, customer, and timestamp.
Per-provider summary
The Payment Gateways configuration panel exposes a per-provider summary — recent volume, refund count, failure rate — so operators see provider health at a glance without leaving SGEN.
Dependency posture
Payment gateways in SGEN depend on each connected provider being available and the credentials staying valid.
Healthy connection
Transactions process within the provider's normal latency. Authorizations succeed at the expected rate. Refunds complete cleanly.
Unhealthy connection
Transactions queue or fail. The configuration panel surfaces the unhealthy state per provider; operators can disable the affected provider while keeping others active to keep checkout open.
Constraints and boundaries
Payment gateways are a Reference area for the connected payment-processing layer. They are not a substitute for per-provider documentation or for SGEN-side subscription billing.
Use this Reference for:
- Understanding the payment-gateway connection model.
- Confirming where transaction state surfaces.
- Diagnosing provider-health questions at the structural level.
- Per-provider product configuration — provider documentation.
- SGEN-side subscription billing — SG-Dashboard Billing.
- Step-by-step setup — Guides.
Public boundary
This page is intentionally public-safe. It does not expose payment credentials, exact API surfaces, or protected operational identifiers.
Examples
Example 1 — Operator connects two providers for checkout flexibility
The operator pairs the site with Provider A for card payments and Provider B for bank transfers. Both providers appear in the configuration panel; both surface transactions in the Orders module. Customers see both options at checkout.
Example 2 — Provider goes unhealthy mid-day
Provider A starts returning transient failures. The configuration panel surfaces the unhealthy state. The operator disables Provider A temporarily, leaving Provider B active to keep checkout open, and escalates to the provider for resolution.
Example 3 — Stakeholder asks "what does SGEN do with the payment data?"
The platform lead opens this page (Definition + Where transactions surface sections) and walks the stakeholder through the model: the provider holds the funds, SGEN records the transaction state, and operators see that state in the Orders module.
Documentation guidance
Use this page as the structural definition for the payment-gateway integration. Procedural detail belongs in Guides; per-release behavior change belongs in What's New or Changelog.Reading order
Open this page when scoping store payment processing or troubleshooting checkout-related questions. Pair with the admin Store Management Reference for the per-module surfaces (Products, Orders, Coupons) where payment-related state surfaces.
Related reading
- Integrations Overview — parent Reference area.
- Email and SMTP — sibling integration covering order-confirmation mail.
- SG-Admin Overview — where Store Management modules live.
- SG-Dashboard Overview — account-tier surface for SGEN-side billing (separate concern).
Vocabulary cross-reference
- Payment gateway is the connected payment-processing provider.
- Provider is the per-gateway service the connection points at.
- Authorization is the approval step that confirms funds are available.
- Capture is the step that moves the authorized amount from the customer to the merchant.
- Refund is the reverse-direction transaction that returns funds.
Maintenance discipline
When the payment-gateway integration changes across releases (new provider supported, new transaction surface, new health-check signal), update this Reference and log the change in Changelog. The connection model stays valuable because the per-provider shape stays small.