Contiant

Open banking payment provider using instant bank transfers. The payer authenticates directly with their bank on a Contiant-hosted page, so no card, IBAN, or account data passes through the Mozarto API.

Operations: Pay-In ✓ | Pay-Out - | Webhook ✓
Processing: Asynchronous - redirect the payer to a hosted page, then receive settlement by webhook
Payment type: Open banking / instant bank transfer

Fields marked with * are required.

Configuration (Mozarto back office)

These fields are in the locked API Credentials section of the account's Processing Scope tab. Unlock it with your 2FA code first - see Unlock API credentials.

Merchant credentials, the beneficiary account, and the payer return URL all live on the PSP configuration, not on the per-transaction request.

Field	Description
`clientId` *	Contiant OAuth client ID
`clientSecret` *	Contiant OAuth client secret
`siteUrl` *	URL the payer returns to after completing or cancelling payment on the Contiant hosted page
`merchantName` *	Beneficiary merchant name shown to the payer
`country`	Beneficiary account country (the merchant's own settlement account country)
`postcode`	Beneficiary postal code. Required for all countries except Direct Flow (NZ/AU)
`iban` / `bic`	Beneficiary IBAN and BIC. Required for every country except Direct Flow (NZ/AU, which need no beneficiary)
`webhookUrl`	Endpoint Mozarto calls with the settlement notification once the payment completes
`notificationSecret`	Signature secret for Contiant's inbound notifications. Mozarto validates the `X-Contiant-Signature` header (HMAC-SHA256) on every notification Contiant sends and ignores any that fail. Take it from your Contiant subscription. Stored per brand, encrypted at rest, and masked in the back office. If left blank, Mozarto processes notifications without signature validation (legacy fallback)

Payment flow and beneficiary requirements

Mozarto uses Contiant's General Flow by default — when the Pay-In request carries no bankId, the payer selects their bank on Contiant's hosted page. Contiant's Direct Flow kicks in whenever a bankId is sent, which happens in two ways: automatically for the two regional methods that require it — POLi (NZ) and PayID (AU) — and on demand when the merchant passes an optional bankId in the Pay-In request (see below). A bankId skips the bank-selection page and sends the payer straight to that bank's authorization step.

The iban/bic is the merchant's own, fixed settlement account — where Contiant deposits the funds. It does not depend on the payer's country, so Mozarto sends the configured beneficiary on every General Flow payment (whichever supported country the payer is in), as long as the beneficiary IBAN + BIC are configured.

Flow	How it is triggered	Beneficiary configuration Mozarto sends
General Flow	No `bankId` sent. Payer countries AT, BE, CY, EE, FI, FR, DE, GR, IE, IT, LV, LT, LU, MT, NL, PT, SK, SI, ES, SE, DK, NO, PL. The payer sees Contiant's bank-selection page and picks their bank there	`iban` + `bic` + `postcode`
Direct Flow (merchant bankId)	For any of the General Flow countries above, the merchant passes an optional `bankId` in the Pay-In request (e.g. `"contiant-mbank"`). This skips Contiant's bank-selection page and sends the payer straight to that bank's authorization step	`iban` + `bic` + `postcode` (same as General Flow — the beneficiary is still required)
Direct Flow (regional)	Applied automatically: New Zealand (NZ) → `bankId: "poli"`, Australia (AU) → `bankId: "payid"`	None. No beneficiary IBAN required; `accountIdentifications` is sent empty

General Flow is the default, but it becomes a Direct Flow the moment a bankId is supplied. For a General Flow country, the behavior depends only on whether the Pay-In request includes a bankId:

`bankId` in the Pay-In request	What happens	Beneficiary sent
Not sent (omitted / empty)	General Flow — the payer lands on Contiant's hosted bank-selection page and picks their bank there	`iban` + `bic` + `postcode`
Sent (e.g. `"contiant-mbank"`)	Direct Flow — the bank-selection page is skipped and the payer goes straight to that bank's authorization step	`iban` + `bic` + `postcode` (unchanged)

Either way the beneficiary (IBAN + BIC + postcode) is identical — the bankId only controls whether the payer still has to choose a bank. A merchant-supplied bankId also takes precedence over the automatic NZ/AU regional default. The bankId is forwarded to Contiant as-is; Contiant validates it and rejects an unknown value.

Supported countries. Mozarto accepts Contiant pay-ins only for the countries listed above. A pay-in for any other country is rejected with a 400 Country not supported error before any Contiant call.

If the required beneficiary configuration is missing (for any non–Direct-Flow country), the Pay-In call returns a 400 configuration error.

Pay-In

POST /v1/api/mozarto/cashier

The cashier call does not move funds directly. It creates a transaction and returns a paymentUrl. Redirect the payer to that URL to authenticate with their bank on the Contiant hosted page.

Request body

Field	Type	Description
`pspType` *	string	Always `"CONTIANT"`
`type` *	string	Always `"PAYIN"`
`baseamount` *	number	Amount in the currency's main unit, up to 2 decimals (e.g. `100` = 100 EUR, `100.50` = 100.50 EUR)
`currency` *	string	Currency code (e.g. `"EUR"`)
`country` *	string	Payer's country - full name, ISO 3166-1 alpha-2, or alpha-3 (e.g. `"Germany"`, `"DE"`, `"DEU"`). See Country codes. Matched against the account's Processing Scope, and converted to alpha-2 before being sent to Contiant. Selects the flow — Direct Flow for NZ/AU, General Flow otherwise (see table above)
`email` *	string	Payer email, forwarded to Contiant
`merchantReference`	string	Your reference for the order, echoed back in the response
`bankId`	string	Optional. A Contiant bank identifier (e.g. `"contiant-mbank"`) to skip Contiant's bank-selection page and send the payer straight to that bank's authorization step. Omit for the standard General Flow where the payer picks their bank. For NZ/AU the regional Direct Flow `bankId` (`poli`/`payid`) is applied automatically, and a value supplied here overrides it. Forwarded to Contiant as-is and validated by Contiant
`webhookUrl`	string	HTTPS endpoint for the status webhook. Overrides the configured `webhookUrl` for this transaction; falls back to the configured value when omitted
`hppSuccessUrl`	string	URL the payer is redirected to after a successful payment. Falls back to the configured Site URL when omitted
`hppFailureUrl`	string	URL the payer is redirected to after a failed payment. Falls back to the configured Site URL when omitted

The payer identity (consumerId, first name, and last name at Contiant) is resolved from the X-User-token, so userId, firstName, and lastName are not required in the request body.

Example request

{
  "pspType": "CONTIANT",
  "type": "PAYIN",
  "baseamount": 100,
  "currency": "EUR",
  "country": "DE",
  "email": "payer@example.com",
  "merchantReference": "Test-001",
  "webhookUrl": "https://example.com/f2e721ba-0ceb-40ea-a388-56e2f584bb7a",
  "hppSuccessUrl": "https://example.com/payment/success",
  "hppFailureUrl": "https://example.com/payment/failed"
}

Response

{
  "status": "success",
  "message": "Successfully",
  "isSuccess": true,
  "data": {
    "paymentUrl": "https://pay.contiant.com/checkout/64a1fa8b9c0d1",
    "transactionId": "64a1f2b3c4d5e6f7a8b9c0d1",
    "merchantReference": "Test-001",
    "amount": 100,
    "transaction_status": "Pending"
  }
}

Field	Type	Description
`paymentUrl`	string	Contiant hosted page URL to redirect the payer to
`transactionId`	string	Mozarto transaction identifier. Use it to match the settlement webhook
`merchantReference`	string	Your reference from the request, or an empty string if none was sent
`amount`	number	The transaction `baseamount`
`transaction_status`	string	Always `"Pending"` at this point. The final outcome arrives by webhook

Redirect the payer to paymentUrl. They authenticate with their bank on the Contiant hosted page and return to the configured siteUrl.

Settlement webhook

Once Contiant reports the payment result, Mozarto sends a POST to your configured webhookUrl. The payload is the same shape for approvals and declines; read transaction_status for the outcome.

{
  "transaction_id": "64a1f2b3c4d5e6f7a8b9c0d1",
  "user_id": "test-003",
  "status": "success",
  "transaction_status": "Approved",
  "amount": 100,
  "currency": "EUR"
}

Field	Description
`transaction_id`	Mozarto transaction identifier returned by the Pay-In call
`user_id`	The payer identifier resolved from the Pay-In request
`status`	Raw settlement result - `success`, `failed`, or `pending`
`transaction_status`	Normalized outcome - `Approved`, `Failed`, or `Pending`. Use this for business logic
`amount`	Settled amount in the transaction currency's major unit
`currency`	Transaction currency

Contiant reports COMPLETED and SETTLED as successful; FAILED, CANCELLED, REJECTED, and ABANDONED as failed. Any other status keeps the transaction pending.

The request carries an Authorization header with a Mozarto-generated signature token. Verify it before applying any balance or state change. See Webhook Setup.

Inbound notification signature (Contiant → Mozarto)

Before Mozarto raises the settlement above, it receives the raw notification from Contiant and validates its authenticity. Contiant signs each notification with an X-Contiant-Signature header:

X-Contiant-Signature: t=1699858882,v1=1191d9f6939a71b4b55fe3a416ae3871dda90c9f9299878e7d078c4a5f0b8e94

t — UNIX timestamp

v1 — HMAC-SHA256("<t>|<raw request body>", notificationSecret) in hex

Mozarto recomputes the HMAC using the brand's configured notificationSecret and compares it to v1. Notifications that fail validation are rejected with 401 and left unprocessed — no transaction update, no merchant forward. If no notificationSecret is configured for the brand, validation is skipped and the notification is processed (legacy fallback).

Error codes

The Pay-In call returns an error when the request cannot be set up. Payment declines are reported later through the settlement webhook with transaction_status: "Failed", not on this call.

HTTP status	Response	When
400	`message: "Country not supported"`	The request `country` is not in Contiant's supported-country list (see above). Rejected before any Contiant call
400	`message: "PSP Configuration not found. Please check you psp Configuration"`	Contiant credentials, `siteUrl`, `merchantName`, or the beneficiary account for the payer's country are missing from the back office configuration
500	`message: "Internal server error"` with the raw failure in `data`	Contiant authentication or payment creation failed

For the full list of errorCode values and retryability guidance, see Errors.

Configuration (Mozarto back office)#

Payment flow and beneficiary requirements#

Pay-In#

Request body#

Example request#

Response#

Settlement webhook#

Inbound notification signature (Contiant → Mozarto)#

Error codes#