C2C-ALL-0006-A-010010

Generated page — source: schema/mpgs.yaml, capabilities/mpgs.yaml, values/mpgs-uat.yaml, data/sku_list.csv. Status: In Development

What is This Product?

C2C-ALL-0006-A-010010 is the MPGS SPF configuration for Consumer-to-Consumer (C2C) ecommerce merchants. It enables two payment flows:

• Token MOTO (PM1): For card-on-file and repeat purchases where the customer's payment details are stored as a token.
• Ecommerce via HPP (PM4): For browser-based card payments through the MPGS hosted payment page, where the customer enters card details directly in a Mastercard-served form.

Card-present (PM0) is not active in this product. The 010010 capability bitmap confirms PM1 and PM4 are provisioned; PM0, PM2, PM3, and PM5 are absent.

This product operates globally — there is no region restriction (ALL in the SKU code).

How This SKU Fits into the Platform

Industry: C2C Ecommerce
        ↓
Solution 0006 → MPGS, Single-Pass Framework (SPF)
        ↓
Variant A → no regional restriction, standard MPGS ecom config
        ↓
Capability Bitmap: 010010
        ↓
PM1 (Token) active         PM4 (Ecommerce) active
        ↓                          ↓
  2 MPG entries               2 MPG entries
  (sync + async)         (widget HPP + processing)

SKU Breakdown

Every part of the SKU code is meaningful. Do not assume readers know the naming convention.

Bitmap decoded:

Supported Transaction Types

Derived from the C2C industry profile and MPGS capabilities. Industry flows are marked SEED in the repository — see OI-009.

Payment Methods Active

See Payment Methods Reference for a full explanation of PM slots and why they exist.

MerchantPaymentGateway Array

This SKU requires four MPG entries. PM0 (Bank Card) is absent because the bitmap does not include PM0. The full MPGS template has five entries — this SKU uses four.

For the full explanation of each entry, see MPG Configuration.

PM1 has two entries because synchronous and asynchronous processing use different channels. The terminal config asyncFlag determines which entry routes each transaction. See Terminal Configuration.

PM4 has two entries because the hosted payment page (widget) is separate from the back-end transaction processing. The widget entry carries no host credentials — MPGS serves the payment form directly. The processing entry carries host credentials and routes the completed transaction to MPGS.

Configuration Workflow

Provision in this exact order. Each step depends on the previous step existing in MGMT.

Step 1 — Group (Optional)

Create a group record only if this merchant belongs to a named group.

Step 2 — Merchant

Step 3 — MerchantPaymentGateway (4 entries for this SKU)

Provision all four entries. Do not provision PM0 (Bank Card) — this SKU does not include card-present capability.

See MPG Configuration for the full field list per entry.

Step 4 — API User

Created automatically from merchant record in SPF flow. Confirm with implementation team whether manual API user creation is required for this SKU.

Step 5 — Terminal

Step 6 — Terminal Config (2 rows per terminal)

Both rows require channelTerminalId and channelMerchantId supplied via secrets manager.

Step 7 — STS (Token Space + Repository)

Environment Values (UAT)

UNCONFIRMED — UAT only. Extracted from values/mpgs-uat.yaml. SIT and PROD values are not in this repository.

Variant Comparison

There is currently one variant (A) in Solution 0006 for the C2C industry. No variant comparison is available.

If a Variant B is introduced (e.g., with 3DS or a different region restriction), a comparison table will appear here.

Open Items

See Also

• Solution 0006 Overview
• MPGS Gateway Overview
• MPGS MPG Configuration
• MPGS Terminal Configuration
• Payment Methods Reference
• SKU Naming Convention