One integration
Your checkout speaks to AGB. AGB speaks to the providers you already hold.
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.
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.
Checkout
Your checkout makes one call and reads one result, whichever provider ended up taking it.
AGB — routing engine
Holds your rule set and the state of every route. It moves instructions and data, never money.
Provider A
First in the order for this transaction, under the contract you signed with it directly.
Provider B
Second in the order, reached without any new action from the customer.
Provider C
Last in the order you configured, and the point at which the result is reported back either way.
Issuer
The issuer approves or declines, not AGB. Money moves between your customer, your provider and your account.
What AGB is
Routing you own
Rules are yours, versioned, and reversible in one action.
Recovery in the attempt
A soft decline is retried inside the same payment attempt.
One data model
The same transaction shape and the same status vocabulary, whichever provider answered.
Signed events
Every state change reaches your endpoint as a signed webhook, with replay.
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
| 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.
-
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.
-
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.
-
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.
-
Report
One dataset across every provider, queryable and exportable.
The same records the routing engine acts on are the records in the report.
The interface
One request. One shape back.
Your team writes against one contract. Which provider answered is a field in the response, not a branch in your code.
# illustrative. the contract is not published yet.
POST /v1/payments
Authorization: Bearer <key>
Idempotency-Key: "3f1c-…-a9"
{
"amount": { "value": "…", "currency": "…" },
"method": "card",
"routing": { "rule_set": "default" },
"passthrough": { /* provider-specific fields, untouched */ }
}# the same shape, whichever provider answered
{
"id": "pay_…",
"status": "authorised",
"attempts": [
{ "provider": "A", "result": "soft_decline" },
{ "provider": "C", "result": "approved" }
],
"provider_raw": { /* kept alongside, never flattened */ }
}# every state change, signed, replayable
payment.created
payment.attempt.started provider=A
payment.attempt.declined soft
payment.attempt.started provider=C
payment.authorised ok
payment.captured okTransaction lifecycle · the same vocabulary for every provider
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.
- 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
The alternative
Building it yourself, or routing through one layer.
| What changes | Direct to each provider | Through AGB |
|---|---|---|
| Adding a provider | A new integration, a new data shape, a new set of edge cases | A routing rule |
| A soft decline | Your code decides what to try next, per provider | Retried inside the same attempt |
| Reporting | One export per provider, reconciled by hand | One dataset across every provider |
| Provider events | One webhook handler per provider | One signed event stream |
| Your contracts | Yours | Still yours. AGB does not sign acquiring contracts |
| Your funds | Settled by your providers | Settled by your providers. AGB never holds money |
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
Incident history and availability. 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.
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.
-
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.
-
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.
-
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.
Questions
The five we are always asked.
Does AGB see card numbers?
No. AGB never stores, processes or transmits card data. The card stays between your checkout and your provider.
Does AGB hold or move money?
No. Settlement runs from your providers to you, on your contracts. AGB moves instructions and data.
Do our rates change?
No. Your commercial terms are between you and your providers. AGB takes no share of a processing rate.
What happens to our existing integrations?
They keep working. Traffic moves gradually, on a percentage split you control, and every rule change is reversible.
Which providers are supported?
Tell us which ones you hold and we will tell you what is already connected and what connecting the rest involves.
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.
info@agbadvans.com
What to include
- Which providers you hold
- Which markets you are in
- What is currently breaking