Payments Overview

Trustist supports both in-face and API-led payment journeys. This guide explains the payment models, who each model is for, and how to choose the right integration path.

Recommendation: default to Open Banking where possible. Card support remains available for coverage and fallback, but Open Banking is the preferred route for new integrations.
Important: the TE API is the core integration surface. The JavaScript SDK is optional and helps speed up browser experiences, but hosted redirect and attempt-driven flows can be implemented directly against the API.

Who This Is For

  • Operations and in-face teams using TrustistTransfer with QR and NFC handoff options.
  • Product teams that want quick go-live using hosted redirects.
  • Engineering teams that need tighter checkout control via embedded or attempt-driven API flows.

Payment Models

Model Best For Payer Journey Merchant Ownership
TrustistTransfer (In-Face) In-person assisted payment collection Staff initiates from TrustistTransfer, payer completes on-device or via mobile handoff (QR/NFC) Low engineering overhead, operational setup in TrustistTransfer
Hosted Redirect Fastest API integration Create payment, redirect payer to payLink, receive return callback You own payment creation, return handling, and status confirmation
Embedded Bank Payment (JS SDK) Bank selector inside your checkout UI Payer selects bank in your page, then top-level redirect to bank authorization You own server-side payment creation and completion handling
Payment Attempts (API) Direct execution control for bank/card attempts Create payment, then create attempt(s), act on requiredAction (for example bank redirect) Highest API control over execution and retries

How To Integrate

  • API-first (no JS SDK): your backend creates payments and attempts, your frontend controls redirects and callbacks.
  • JS SDK-assisted: SDK provides hosted/embedded browser helpers, while your backend still owns API calls.
  • Custom/homespun UI: you can fully own the checkout UI and only use TE API endpoints.

Hosted Redirect Works With or Without JS SDK

  1. Create payment via POST /v1/payments.
  2. Read payLink from the response.
  3. Redirect payer to payLink from your own frontend or server flow.
  4. Handle your returnUrl and confirm using GET /v1/payments/{paymentId} and webhooks.

The JS SDK is a convenience layer for browser integration. It is not required for TE API payment processing.

Open Banking and Cards

Method Positioning Notes
Open Banking Primary recommendation Supports hosted, embedded, and attempt-driven flows. Bank choice can be controlled via /v1/banks.
Card Secondary / fallback Supported in attempts flow and legacy hosted patterns. Keep for coverage where required.
Card attempt compliance: if you use card payment attempts and handle raw card details in your systems or pages, you are likely in PCI DSS scope. Validate your compliance obligations before going live.

Core Payment Objects

  • Payment: commercial intent (amount, reference, return URLs, context).
  • Payment Attempt: execution record (bank/card input, status, required action, retries).

In attempt-driven integrations, create the payment once and create new attempts as needed.

Baseline API Flow

  1. POST/v1/payments to create the payment.
  2. (Optional, bank flows) GET/v1/banks?countryCode=GB&paymentRails=FASTER_PAYMENTS.
  3. Either redirect to payLink (hosted) or create an attempt via /v1/payments/{paymentId}/attempts.
  4. If requiredAction.url is returned, redirect the payer immediately.
  5. Use webhooks as source of truth; use GET /v1/payments/{paymentId} for pull confirmation when needed.

Related Payment Features

  • QR mobile handoff: available in hosted and embedded JS SDK journeys.
  • NFC assignment: set nfcOptions on payment creation when using tag-based flows.
  • AIS-gated payments: require bank access scopes before payment execution.
  • MOTO mode: available for assisted/manual card capture scenarios.

Where Next