Moneygate
PSD2 B2B API Specification

Moneygate developer documentation

PSD2 B2B API Specification

The Moneygate PSD2 B2B API is the external REST interface for integrations that need account, client, and transaction information through authenticated HTTPS requests.

Clients Accounts Transactions OAuth token

Integration guide

This guide helps developers connect to the Moneygate PSD2 B2B API. It includes the environment URLs, authentication flow, available operations, downloadable integration files, and links to the live Swagger reference.

Source of truth. For exact request fields, response models, and required properties, use the OpenAPI document exposed by the deployed API.

Getting started

What Moneygate issues

Use the shared UAT demo credentials below to start testing. Production credentials are issued separately after the UAT integration has been tested successfully.

UAT

API base URL
https://b2b-api-uat.moneygate.com
Token URL
https://demo.auth.moneygate.com/connect/token
Client ID
b2b-psd2-uat-resourceowner
Username
860871
Password
Password123!

Production

API base URL
https://b2b-api.moneygate.com
Token URL
https://auth2.moneygate.com/connect/token
Credentials
Contact Moneygate after successful UAT testing.

Call sequence

  1. Use the UAT demo client ID, username, and password shown above.
  2. Request an access token from the token endpoint.
  3. Send the token on each API request as a bearer token.
  4. Use Swagger or the Postman collection to test the available operations.

Authentication

The API uses JWT bearer authentication. First request an access token from the identity provider, then include that token on every API request.

Credential delivery. Use the shared credentials in this guide for UAT testing. Moneygate provides client-specific production credentials after successful UAT onboarding.

Token request

Send a form-urlencoded POST request to the token endpoint for your environment.

client_id={{client_id}}
grant_type=password
username={{username}}
password={{password}}

Bearer header

Use the returned access token on every request to the Moneygate B2B API.

Authorization: Bearer {{access_token}}

API flows

About these flows

Your system is the integration calling the API. Diagrams show the typical order of calls. Exact paths, parameters, request bodies, and response fields are available in the Swagger UI.

Most integrations follow the same pattern: obtain an access token, send authenticated HTTPS requests to the Moneygate B2B API, then process JSON responses shaped by the published contract.

List and search calls can include paging query parameters such as PageNumber and PageSize. Paging starts at PageNumber=0.


Before each call: token and request

Token and API request sequence Your system Token endpoint Moneygate B2B API Your system Token endpoint Moneygate B2B API Request access token Access token HTTPS request with bearer token Validate token and request JSON response

Every operation below assumes the bearer token is valid.


Typical call: list clients and load accounts

Many integrations first list the clients available to the authenticated user, then load accounts for the selected client.

Client and account lookup sequence Your system Moneygate B2B API Your system Moneygate B2B API GET /api/Clients/summary 200 client summary list GET /api/Clients/{clientId}/accounts 200 account list

Typical call: search and open a transaction

Use the search endpoint to retrieve matching transactions, then open a specific transaction when the user needs its full details.

Transaction search and details sequence Your system Moneygate B2B API Your system Moneygate B2B API POST /api/Transactions/search Apply filters and pagination 200 transaction result page GET transaction details by account/reference 200 transaction details

Published resource groups

Swagger groups the available operations roughly as follows:

  • Clients - list client summaries and load accounts for a client.
  • Accounts - access account-scoped transaction details.
  • Transactions - search transactions using request filters and pagination.
  • Authentication - obtain and use a JWT bearer access token.

API reference

The live Swagger/OpenAPI document is the contract for operations, schemas, response codes, and model fields.

Published operations

Method Path Purpose
GET /api/Clients/summary?PageNumber=0&PageSize={pageSize} Get the client summary information available to the authenticated user.
GET /api/Clients/{clientId}/accounts?PageNumber=0&PageSize={pageSize} Get accounts for a particular client.
POST /api/Transactions/search?PageNumber=0&PageSize={pageSize} Retrieve transactions using request body filters and pagination parameters.
GET /api/Accounts/{accountNumber}/Transactions/{referenceNumber} Get the details of a particular transaction.

Error handling

Errors use standard HTTP status codes and problem details where applicable.

Status Meaning Integrator action
400 Invalid request or validation failure. Check required fields, route values, query parameters, and JSON body.
401 Unauthorized or missing/expired token. Request a new token and retry only when safe.
403 Token accepted, but operation is not permitted. Confirm user role, client access, and configured API scope with Moneygate.
404 Resource not found. Verify identifiers such as account number, client ID, and reference number.
500 Internal server error. Retry later or contact Moneygate support with request details.

Security

  • Use HTTPS for every token and API request.
  • Store credentials in a vault or secure configuration store.
  • Never embed credentials in source control, mobile apps, or public documentation.
  • Keep machine clocks reasonably aligned with UTC to avoid token expiry issues.
  • Log request identifiers and timestamps, but do not log access tokens or passwords.

Downloads

Use these files to test and share the current integration package.

Support

If an integration cannot authenticate or receives unexpected validation responses, contact support at support@moneygate.com and include a short description of the case.

Production access. Production credentials should be issued only after the UAT integration has been tested successfully.
↑
Copied to clipboard