Integrate a Payment Provider

This guide covers direct mobile payment — a shopper paying on their own device via a payment app, as described in Business Flows: Payment. It does not apply to POS Handover: when payment happens at a POS or SCO instead, My-Scan never calls a payment provider at all — the POS/SCO owns payment entirely. If you're integrating a new POS, see Integrate a New POS instead.

What the Core Service needs from you

No code change, and no new endpoint, is required in the Core Service to support a new payment provider. Every payment request the Core Service makes goes to the same HiiConnect Payment Router and Response Outbox, using the same paths, regardless of which provider is actually processing the payment underneath — provider routing is entirely a HiiConnect-side concern, configured once a Payment Service Provider (PSP) Connector is provisioned there for the tenant/business unit.

What the Core Service does need is the right values for PaymentSettings — not itself a parameter, but a class grouping five tenant-level parameters:

Setting	Default	Purpose
CountryCode	SE	Market the tenant operates in
Currency	EUR	Transaction currency
UserLanguage	en	Language shown to the shopper during payment
ReceiptLanguage	en	Language used on the printed/digital receipt
TenderType	SPAY (Softpay)	Identifies the tender/payment method on the receipt and in back-office reporting

TenderType is the one setting that's actually specific to the payment provider — it's recorded on the tender registered with the Checkout Engine, and needs to match whatever code the retailer's back office expects for that provider. The provider's identity on the tender's ProviderInfo.ProviderId field, by contrast, is filled in automatically from HiiConnect's response — you don't configure that.

Getting the correct information

Before configuring anything, gather:

1. Confirmation the provider is live and routed — someone managing the tenant's payment setup with the HiiConnect/Payments team needs to confirm a PSP Connector for the new provider is deployed and routed for this tenant and business unit. My-Scan's configuration can't verify this on its own — a correctly configured TenderType with no PSP Connector routed on the HiiConnect side will still fail at payment time.
2. The correct TenderType value — ask whoever owns the retailer's tender-code mapping (typically the same people confirming the routing above) what code identifies this provider in their back office/POSLog.
3. Market settings — confirm Currency, CountryCode, UserLanguage, and ReceiptLanguage match the tenant's market, if they differ from the defaults.

Set the parameters

Each of these is a tenant-scoped Parameter — not CCC, since it's not something a retailer edits themselves through a portal. Follow Add a New Parameter for the general mechanics; for this specific setting:

• Cloud — set the tenant override in appsettings.Cloud.json. Cloud matches a JSON key to a PaymentSettings property by stripping underscores and comparing case-insensitively, so the key must reduce to exactly the property name — TenderType needs a key like TENDER_TYPE (or TENDERTYPE), not a key with any extra word in it:

  {
    "TENANT_SETTINGS": {
      "<tenantId>": {
        "TENDER_TYPE": "YOUR_PROVIDER_CODE"
      }
    }
  }

  Only override the keys that need to change for this tenant — anything you don't set falls back to DEFAULT_SETTINGS. Since this is a tenant-level parameter, it's set directly under the tenant, not nested under BUSINESS_UNITS.

• OnPrem — set the parameter in PROGRAMPARAMETERS under program MyScan.Core.Service (OnPrem is single-tenant, so there's no separate tenant scope to set).

Verify

• Start a direct-mobile-payment trip against a test tenant with the new provider live, and confirm it completes.
• Check the resulting receipt/tender shows the TenderType you configured.
• If you can force a decline or timeout, confirm the abort/reversal path behaves as expected — see Business Flows: Payment for the success/failure sequence.