Endpoint Solutions Overview

Before you open any gateway configuration page, read this. It takes five minutes and will make every other page in this portal make sense.

The Platform in One Sentence

This platform provisions merchants onto payment gateways by writing configuration to a chain of MGMT API endpoints — in a fixed order — so that each payment method a merchant supports has a complete, connected set of records.

1. The Provisioning Dependency Chain

The seven-object view is useful, but it is only the top-level abstraction. The real provisioning flow in the Jinja template is a dependency chain: each provisioning context must be created in the right order because downstream objects depend on the ones that came before them.

The current template in templates/mpgs-uat.j2 materializes this flow as a sequence of provisioning contexts: group, merchant, mpg, apiuser, terminals, terminalconfigs, and sts. The STS portion is especially important because it contains sub-steps that are conceptually separate even though they sit under one STS block in the template.

Group (optional)
  └── Merchant
        ├── MerchantPaymentGateway entries ×N
        ├── API User
        └── Terminal(s)
              ├── TerminalConfig rows ×N
              └── STS context (if token flows are needed)
                    ├── Token Space
                    ├── Token Repository
                    ├── STS API User / access principal
                    └── Token-channel permissions

Why does order matter? The provisioning graph is sequential. You cannot create a MerchantPaymentGateway before the Merchant exists, you cannot create TerminalConfig before the Terminal exists, and you cannot create STS repositories or access grants before the STS token space exists. The Jinja template encodes this order so the automation can materialize the full workflow in one run.

Note: The repository currently exposes the STS setup as a single sts block in the template, with sub-objects for token space, repository, API user, and token-channel config. If a future version introduces separate STS user objects or additional permission objects, they should be added as additional dependency steps in this sequence.

2. SKU Naming Convention First

Before you read any schema or gateway detail, start with the SKU naming convention. A SKU is a five-segment code that uniquely identifies a merchant product configuration. Every field in the system traces back to the SKU — it determines which gateway is used, which payment methods are active, and which schema fields apply.

C2C  -  ALL  -  0006  -  A  -  010010
 │       │       │       │      │
 │       │       │       │      └── Capability Bitmap (6 bits, one per PM slot)
 │       │       │       └───────── Variant letter
 │       │       └───────────────── Solution ID → maps to a gateway + integration
 │       └───────────────────────── Region code (ALL = global)
 └───────────────────────────────── Industry code

Decoded example — C2C-ALL-0006-A-010010:

See SKU Naming Convention for the full reference.

3. What Are Payment Method Slots?

A payment method slot (PM slot) defines a channel of payment acceptance. Each active slot in a merchant's bitmap requires at least one MerchantPaymentGateway entry — sometimes two if the gateway splits the same slot into sync and async processing modes.

The bitmap tells you exactly how many MPG entries to create:

MPGS PM1 has two entries; Adyen PM1 has one. The gateway determines the entry count per slot — not the bitmap alone. Always read the gateway's MPG Configuration page alongside the bitmap.

See Payment Methods & Capability Bitmap for the full reference including role identifiers.

4. Solutions and Gateways

A Solution ID maps an industry product to a specific gateway and integration pattern. The solution determines which schema file applies and which gateway configuration pages to follow. For new work, microservice-based solutions are the preferred target state. SPF solutions remain documented for backward compatibility, reference, and migration planning while the platform transitions over time.

Note

• SPF (Legacy Architecture): uses a single integration endpoint where payment methods share a common integration model. Configuration is centralized, resulting in a simpler provisioning workflow.

• MS (Current Architecture - Recommended): uses a microservice-based architecture where individual capabilities are provisioned and configured as independent services. This introduces additional configuration and provisioning steps while enabling capability-specific deployment and management.

See Solution IDs for the full reference.

5. Active Products (SKUs)

The portal currently documents the following active SKUs:

Documentation References

The documentation is organized by task. Use the following pages based on what you need to perform.