AGB Talk to our team

Payment orchestration and infrastructure

Add a provider without
adding an integration.

AGB is the technical layer between your checkout and the providers you already hold. Your contracts and your rates stay exactly where they are.

Talk to our team See how routing works

Payment flow diagram

The checkout sends one transaction to the AGB routing engine, which holds three outbound routes: Provider A, Provider B and Provider C. Whichever provider takes the attempt passes it to the issuer. Selecting any node explains it in the panel below.

Payment flow: checkout, routing engine, three providers, issuer A directed diagram. One edge runs from Checkout to the AGB routing engine. Three edges fan out from the routing engine to Provider A, Provider B and Provider C. Three edges converge from those providers onto the Issuer. Checkout AGB Routing engine Provider A Provider B Provider C Issuer
Payment flow: checkout, routing engine, three providers, issuer The same diagram drawn top to bottom. Checkout at the top, the AGB routing engine below it, Provider A, Provider B and Provider C side by side beneath the engine, and the Issuer at the foot, with every provider feeding into it. Checkout AGB Routing engine Provider A Provider B Provider C Issuer

AGB — routing engine

Holds your rule set and the state of every route. It moves instructions and data, never money.

How it works

A decline is not the end of the transaction.

Routing picks the provider before the attempt. Cascading retries the ones that fail, within a single payment attempt, before the customer sees anything.

Your contracts, your rates and your funds flow stay with your providers. AGB is the layer that connects them. Routing decisions are made on performance alone, because we have no book of our own to feed.

Simulated failover sequence

SIMULATED SEQUENCE — CLICK TO REPLAY
Attempt Provider Result
Attempt 1 Provider A soft decline
Attempt 2 Provider B no response
Attempt 3 Provider C approved

A simulated sequence, not live traffic.

AGB connects to the providers you already work with. Tell us which ones you hold and we will tell you what is already supported and what connecting the rest involves.

One integration

One object. One stream. No per-provider branching.

Every provider returns the same transaction shape, the same status vocabulary and the same error taxonomy.

  1. Connect

    Add a provider once and it is available to every rule, flow and report.

    When a provider changes its API, that is our work, not yours.

  2. Accept

    A server-to-server API.

    AGB passes a reference to a payment instrument issued by your provider, and takes no part in capturing card details.

  3. Reconcile

    Transaction records and statuses are normalised across providers into one dataset.

    A mismatch between what a provider reports and what your system recorded is surfaced, not silently absorbed.

  4. Report

    One dataset across every provider, queryable and exportable.

    The same records the routing engine acts on are the records in the report.

In code

One integration, not six. Signed events for everything after.

One request authorises a payment through whichever provider the rules pick. Provider-specific fields are passed through, not flattened away.

One integration instead of many

Two views of the same set of connections. In the first, your systems hold a separate integration to each of six providers: six connections to build, six to watch and six to keep current, and they cross one another because each one is its own piece of work. In the second, your systems hold one integration to AGB, and AGB holds the connection to each of the same six providers. The six providers, labelled Provider A to Provider F, are identical in both views; what changes is how many connections you own. The second view is the one shown first. The button below switches between them.

One integration instead of one per provider Left to right. Your systems on the left, six providers in a column on the right. One view draws six separate connections from your systems to the six providers, each tagged Integration, crossing one another on the way. The other draws a single connection from your systems to AGB, tagged Integration, and six connections from AGB out to the same six providers. Integration Integration Integration Integration Integration Integration Six integrations to build, watch and keep current. AGB one integration Integration One integration. AGB keeps the rest current. Your systems Provider A Provider B Provider C Provider D Provider E Provider F
One integration instead of one per provider The same comparison drawn for a narrow column. Your systems at the top left, six providers in a column down the right. One view runs six separate connections, each tagged Integration, out to the six providers, crossing one another. The other runs a single connection, tagged Integration, from your systems down to AGB, and six connections from AGB out to the same six providers. Integration Integration Integration Integration Integration Integration Six integrations to build, watch and keep current. AGB one integration Integration One integration. AGB keeps the rest current. Your systems Provider A Provider B Provider C Provider D Provider E Provider F
  • Every state change is published to your endpoint as a signed webhook, with replay for anything your endpoint missed
  • Idempotency keys on every write
  • Access is role-based, and every configuration change — routing rules included — is recorded with an actor and a timestamp

Engineering

Built to be tested.

Everything below is something your team can check before anything is signed. Where a capability is not ready yet, it says so.

  • Readiness:

    OpenAPI specification

    The full contract as a machine-readable document. Import it into your client of choice, generate a typed client, or diff it between releases.

  • Readiness:

    Sandbox with deterministic outcomes

    Test values that always produce the same result — a soft decline, a timeout, a recovery on the third attempt. Your error handling gets written before you see live traffic, not after.

  • Readiness:

    Documentation and changelog

    Every endpoint documented and every change dated, so you can see what moved between releases without asking us.

  • Readiness:

    One error vocabulary

    Provider decline reasons mapped to a single taxonomy, with the raw provider response kept alongside it. Your team writes one handler instead of one per provider.

  • Readiness:

    Versioned routing rules

    Every change to a rule is a version with an author and a timestamp. Any previous state can be restored in one action.

  • Readiness:

    Shadow mode

    A copy of live traffic is evaluated by AGB without touching the transaction your customer is making. You compare outcomes on your own numbers before anything moves.

  • Readiness:

    Status page

    Uptime and incident history, published. You find out from us, not from your customers.

  • Readiness:

    Read-only demo environment

    A working dashboard populated with synthetic data. See the product before a contract, without sending us anything of your own.

Marketing services

Marketing services, run as a separate practice.

A standalone service line. Tell us what you are trying to grow and we will scope it.

  • Brand and positioning

    What you stand for, and how that gets said.

  • Content and creative

    The work that carries it.

  • Campaign delivery

    Putting it in front of the right people.

  • Measurement and reporting

    What worked, in numbers you can check.

Discuss a marketing brief

Getting started

Three steps, and one honest conversation first.

We would rather tell you in week one that your stack does not need us than discover it in month three.

  1. Map the stack.

    You tell us the providers you hold, the methods you need and the markets you are in. We tell you what is already connected, what is not, and what connecting the rest involves.

  2. Integrate against sandbox credentials.

    Sandbox credentials are issued after basic onboarding checks, so your team can integrate against the real API while commercials are still open.

  3. Move traffic gradually.

    Start with a percentage split on a single flow, compare against your existing path on your own numbers, and increase it when you are satisfied. Rules are versioned, so any change is reversible.

You have a named contact on your account from day one.

Talk to our team

Contact

Tell us what your stack looks like.

Tell us what your stack looks like and we will tell you what we would connect, in what order, and what it would take.

What to include

  • Which providers you hold
  • Which markets you are in
  • What is currently breaking