Skip to content

Build on one API contract. Own the integration.

Connect onboarding, payments, settlement, risk and reporting to your platform. Build through direct HTTP, an available SDK or approved tooling with workspace-scoped access and a controlled route to production.

Request developer access

MCP-first integration. Direct API when you need it.

Use approved MCP tooling for a reviewable first pass, map an existing schema, or build directly with HTTP or an available SDK. Choose the route that fits your architecture and access; test it in sandbox before production approval.

  1. Agent-assisted / MCP

    Preferred route · engineering-reviewed changes

    Partner preview

    Use permissioned MCP tooling to inspect your schema and the API contract, then propose implementation changes. Your engineers review the diff and approve application.

    • Inspect schema structure with read-only access.
    • Review additive changes and dry-run before applying.
    • Verify the integration with a sandbox request or payment.
    View an illustrative agent brief
    Reviewable implementation briefinstruction
    With approved PayFacLite® agent tooling and scoped sandbox access:

Inspect the customer, merchant, payment and ledger tables we already operate.
Map them onto the PayFacLite® operating families.
Propose an additive integration. Do not remove or rewrite what exists.
Prepare the change as a diff for review. Do not apply it.
Once the diff is approved, dry-run it against sandbox.

    Illustrative brief, not a connection command. Agent tooling is in partner preview; changes require engineering review and production approval.

  2. Schema mapping

    Preserve your data model

    Partner preview

    Supply schema definitions or table names, rather than row data. Map your existing merchant, customer, payment and ledger structures to the contract.

    • Review proposed mappings and unmapped structures.
    • Inspect generated migration and rollback scripts.
    • Dry-run changes before approved application.

  3. Direct API / SDK

    Conventional route · own the implementation

    HTTP Approved teamsSDKs Partner preview

    Implement against the versioned HTTP contract or an SDK available for your stack. Your team controls request handling, event processing and the release pipeline.

    • Implement requests, responses and error handling.
    • Verify signed webhooks and handle retries.
    • Test state transitions before production approval.

The contract stays the same.

If agent-assisted tooling is unavailable or not the right fit, build through direct HTTP or an available SDK against the same contract. Engineering review, sandbox validation and production approval still apply.

Before you build

  • Contract scope

    Confirm resource coverage, schemas, error cases and version dependencies.

  • Access boundaries

    Agree workspace permissions, credential ownership and environment separation.

  • Operational readiness

    Assign event handling, recovery, release approval and live-support ownership.

Explore the API families.
Understand the contract.

Navigate partner and merchant API families, inspect their resources and operations, and understand the request and response structures your integration will use.

API scope

Enterprise / Partner

Customer, seller and programme-level API families.

  • Customers
  • Transactions
  • Business Hub
  • Profile
  • Sellers
  • Seller Groups
  • Support
  • Notification Settings

API scope

Enterprise / Merchant

Merchant-scoped payment, settlement, account and workspace API families.

  • PaymentsExample below
  • Paylinks
  • Settlements
  • Banking
  • Account
  • Workspace

Inside an API family

Payments

A family groups related API operations. In Payments, the bundle response exposes transactions and chargebacks; separate operations handle receipts, records and refunds.

Scope
Enterprise / Merchant
Family
Payments
Bundle response sections
transactionschargebacks

Selected operations

  • GET
    Retrieve the payments bundle
    /api/v1/enterprise/merchants/customers/{customerId}/payments

    Response sections: transactions and chargebacks.

  • POST
    Email a transaction receipt

    Receipt operation for a transaction.

  • GET
    Download a transaction record

    Download operation for a transaction.

  • PUT
    Refund a transaction

    For supported transactions, subject to permissions.

Request · placeholder valueshttp
GET /api/v1/enterprise/merchants/customers/{customerId}/payments
Host: sandbox.example
Authorization: Bearer <sandbox-token>
Accept: application/json
Response shape · illustrativejson
{
  "transactions": [],
  "chargebacks": []
}

Path from the Connect API Explorer. Host, customer ID and token are placeholders; the JSON shows response sections, not live data or the full schema. Use your workspace’s versioned reference for parameters, field types, permissions and errors. Banking and account capabilities depend on programme eligibility.

Explore the contract.
Test the integration.

Use the Connect workspace to explore resources, run sandbox requests and test the events your integration depends on.

Inside Connect · developer workspace

  • API Explorer

    Explore the contract.

    Browse API families and resources. Inspect request parameters and response structures before mapping them into your application.

    Resource families · requests · responses
  • API Playground

    Execute in sandbox.

    Compose a request, inspect the sandbox response and switch between generated SDK, raw HTTP and MCP call examples.

    Compose · run · inspect · copy
  • Webhook triggers

    Verify event handling.

    Edit test payloads and trigger sandbox events for settlement, reports, sales, refunds and cancellations against your configured endpoint.

    Test payloads · endpoint delivery · results

Tools and resources depend on your approved workspace access. SDK and MCP availability follows the release status shown on this page.

Request workspace access

Integration walkthrough · illustrative

From your schema to a sandbox proof.

Start with the model you already own.

Review table and column names, then identify the customer, merchant and payment structures to map. Keep row data out of the schema review.

Read-only inspection. No application changes.

Review input · example checklist
  • Schema definitions only
  • Existing structures identified
  • Unmapped tables flagged for review
What if the receiving endpoint is unavailable?

  1. Inspect the failure

    Review the delivery trace and endpoint response. Check availability and configuration before retrying.

  2. Recover the receiver

    Restore the endpoint, verify signatures and guard against duplicate processing using the event identity defined by the contract.

  3. Verify recovery

    Inspect the next delivery or use supported replay controls. Confirm the intended application state, not just an HTTP acknowledgement.

Illustrative recovery scenario, not a live incident. Retry policy and replay permissions are workspace-specific.

Illustrative walkthrough based on Connect workflows, not a live session or executable integration. MCP and schema tooling are in partner preview; access and supported operations depend on your workspace.

Choose HTTP or an SDK
for your stack.

Direct HTTP is available to approved integration teams. SDK clients are in partner preview; confirm language coverage and release status before making them an implementation dependency.

  • TypeScript and Node
    Partner preview
  • Python
    Partner preview
  • Go
    Partner preview
  • .NET
    Partner preview
  • Ruby
    Partner preview
  • iOS and Swift
    Partner preview
  • Android and Kotlin
    Partner preview
  • PHP
    Partner preview

SDK and HTTP implementations use the same request, response, permission and event contract.

Confirm the client, supported version and installation instructions through your approved workspace. This list is not a public package-release catalogue.

Request SDK access

Isolate environments.
Scope access.

Treat credentials, webhook destinations and configuration as environment-specific dependencies. Agree the access and promotion controls before implementation begins.

Separate environments

Use the separate sandbox and production base URLs and credentials supplied for your workspace. Keep test configuration and production access distinct, with promotion subject to approval.

Credentials and controlled updates

Manage webhook signing secrets and operational alert destinations through the workspace controls available to your team. Confirm rotation, revocation and configuration-change procedures before launch.

Workspace configuration

  • Base URLs
  • Notification destination
  • Signing secrets
  • Configuration changes
  • Environment separation

Base URLs, credentials and signing secrets are supplied through the approved workspace, not this public page.

  • Manage API key access.

    Create, label and search API keys. View ownership, status and creation dates, and revoke credentials when access is no longer required.

  • Connect your device estate.

    Manage registered devices and SoftPOS licences, with visibility of customer associations, licence status and integrated or standalone modes where enabled.

Build for delivery
failures and recovery.

Verify webhook signatures before processing a payload. Monitor delivery state, handle retries and plan how your service recovers when an endpoint is unavailable.

  1. 01

    Event created

    A state change raises an event against the contract.

  2. 02

    Signed delivery

    The payload is signed, and your endpoint verifies the signature.

  3. 03

    Retry policy

    A failed delivery is retried on a configured exponential backoff.

  4. 04

    Dead-letter queue

    Repeated failure moves the delivery aside rather than dropping it.

  5. 05

    Replay

    A held delivery is inspected and replayed once the endpoint recovers.

Signed payloads
Every delivery carries a signature your systems verify before acting on it.
Endpoint registration
Configure distinct sandbox and production destinations, and check each environment’s signing and access settings.
Event filtering
Subscribe to the events your product acts on rather than the whole stream.
Delivery diagnostics
Inspect event payloads, headers and delivery traces to investigate failures and check how your endpoint responds.
Retry and backoff
Confirm which failures are retried, the backoff schedule and the retry limit for your workspace.
Dead-letter and replay
Inspect held deliveries and use supported replay controls after recovery. Confirm retention and replay permissions for your workspace.

Event family patternsmerchant.*payment.*settlement.*risk.*

Confirm payload schemas, retry configuration and supported replay operations in the reference for your workspace. Event patterns shown here are not individual event names or delivery guarantees.

Make production readiness explicit.

Agree ownership of data mapping, event handling, configuration and operating hand-offs. Technical verification and programme approval are separate requirements for launch.

  1. Assess and map

    Understand the product, data model and required operating scope.

  2. Build and test

    Integrate through the chosen technical route in sandbox.

  3. Review and validate

    Confirm data mapping, event handling, controls and operational readiness.

  4. Promote with control

    Move approved configuration and integrations into production.

  5. Operate and evolve

    Manage version changes, event delivery, releases and ongoing improvement.

Progression to production follows technical and programme approval.

Plan for versions,
retries and change.

Evaluate the contract as a long-lived dependency: versioning, deprecation, migration, test coverage and operational ownership matter beyond the first successful request.

Additive change
Integration changes are additive and reviewable rather than destructive.
Idempotency and retries
Idempotent request and retry handling, where the operation supports it.
Explicit versioning
The API is versioned explicitly, and deprecation is communicated rather than inferred.
Controlled migration
Plan migration from superseded API versions against the published deprecation window and available support.
Sandbox before production
Changes are exercised in sandbox before any promotion to production.

Confirm idempotency and reversibility per operation in the reference. These practices are not uptime, performance or zero-downtime guarantees.

Integration surfaces

Tools & availability
  • SDK

    Maintained clients in the languages your team ships

    Partner preview
  • Raw HTTP

    One REST contract, called directly from any stack

    Approved teams
  • MCP and agent-compatible tools

    A governed interface for an approved development agent

    Partner preview
  • Signed webhooks

    Receive the supported events your integration subscribes to

    Approved teams
  • API playground

    Explore the families and exercise calls against the reference

    Approved teams
  • Sandbox

    Exercise supported requests and event flows before production approval

    Approved teams

Bring your stack.
Prove the integration.

Start with one concrete use case. Review the contract, agree access and define the sandbox test that will prove it fits your application.

  1. Bring your context

    Your language and framework, a schema outline without row data, and the API families or events you need.

  2. Agree the access

    Confirm workspace scope, available tooling, security requirements and who owns technical questions and delivery.

  3. Define the first proof

    Choose a sandbox request and webhook test, agree success criteria, then review the evidence before production planning.

Request a technical review of your use case. Do not include API keys, customer records or production credentials.

Request developer access

Acquiring infrastructure for international platforms.

Build and operate across the UK, Europe and the United States from a single governed PayFacLite® operating foundation.

  • United Kingdom

    Regulated acquiring foundation

  • Europe

    Infrastructure for multi-market propositions

  • United States

    Infrastructure for international growth

Market availability depends on programme structure, product scope and applicable regulatory requirements.

  • Verofy Ltd (trading as Verofy® Acquiring) — FCA Authorised Payment Institution
  • PCI DSS Level 1
  • Safeguarding in line with regulatory requirements
  • United Kingdom
PFL Trust Centre

What will you build?

Keep control of the customer relationship, shape a proposition that’s yours, and create more value in your business. We’ll help map the right operating model.

Book a 30-minute workshop

A clear view of your platform route.

Your proposition
Who it serves and what it offers.
The operating model
Where the regulatory boundary sits.
Delivery and integration
How your team connects and goes live.

Email us: enterprise@payfaclite.com

Call us: 0330 088 1251

Visit us: Bank House, Manchester.