Card and account to account rails, one path
An authorisation has a deadline. Every check spends part of it. We resolve card preferences, limits by payment type, balance and fraud in one pass, inside a budget you can defend.
p95, request to authorisation decision. Requirement was 200 ms
Card preferences, limits by payment type, balance and fraud
By design, not by patch
Capabilities in payment orchestration
Card authorisation
Routed via Thredd for Visa and Mastercard, Apple Pay and Google Pay included, with the decision made internally, inside the window: card preferences, limits (card present, card not present, Apple Pay and Google Pay, ATM cash), balance and fraud in one pass.
Account to account rails
Domestic batch and real time account to account rails behind the same interface as the card path. In Australia that was Direct Entry, NPP, PayID and PayTo, implemented with Cuscal, including solicited and unsolicited returns, tested against partner sandboxes with contract tests and replayable fixtures.
Idempotent money movement
Every transfer carries its own key, so a retried or replayed message is the same operation rather than a second payment.
Transaction enrichment
Merchant and transaction enrichment through Look Who's Charging and Snowdrop, so a statement line names who was paid and a dispute starts from the facts.
Integration surfaces we know from the inside
- Threddcard processor, for Visa and Mastercard issuing · Shaype, 2018 to 2023
- Apple Pay and Google Paythrough Thredd · Shaype, 2018 to 2023
- Cuscalaccess to Australia's batch and real time account to account rails (Direct Entry, NPP, PayID and PayTo), including solicited and unsolicited returns · Shaype, 2018 to 2023
- Look Who's Charging and Snowdroptransaction enrichment · Shaype, 2018 to 2023
Entries marked Shaype, 2018 to 2023 were built while Marius Telespan was Shaype's Head of Engineering. They are his track record, not Sofitect engagements.
Replacing a card processor integration
We have not moved a live card portfolio from one processor to another, and we say so. What we do have is the integration itself, in depth: our managing director, Marius Telespan, implemented Thredd at Shaype as its Head of Engineering. The 93 ms authorisation path on this page was built there in the same period, 2018 to 2023. Neither was a Sofitect engagement. This is how we would run a replacement, written before we have done one, so you can judge the plan and not the claim.
- 01
Inventory before plan.
Every call your platform makes to the processor and every file it receives, listed and owned: card issue and lifecycle, authorisation, 3D Secure, tokens, PIN, disputes, settlement and fees. The list is the scope. Anything not on it gets found at cutover, which is the wrong place to find it.
- 02
Cohorts are account ranges.
The schemes route an authorisation by account range, not by customer, so a cohort is a range, never a product segment inside one. Each is one of three things: a range you hold, repointed at the schemes; a reissue onto a new range; or one processor bridging to the other. We would settle which, per range, with the sponsor and the schemes, and price all three.
- 03
Card data under PCI DSS.
Moving a card moves its PAN, expiry, status and PIN between two PCI DSS environments, and the transfer is in scope end to end. PIN blocks are translated between the two processors' HSMs under keys exchanged in a ceremony with split custodians, never in the clear. The issuer keys behind chip cryptograms and card verification values move the same way, or that cohort is reissued.
- 04
Tokens at wallets and at merchants.
A card added to Apple Pay or Google Pay before the move must still pay after it. The quieter breakage is card on file: network tokens held by a streaming service or a ride app, mapped to the PAN by the schemes. Where the PAN stays, the new processor takes over their lifecycle messages; where it changes, Visa Account Updater and Mastercard Automatic Billing Updater repoint them.
- 05
Disputes and history.
A chargeback open on the day its cohort moves stays with the incumbent until it closes, scheme case and clocks unchanged, and one named person reads both queues until the last closes. Customer transaction history lives partly at the processor; it is exported to your platform before the move, so no statement or subject access request depends on a contract that is ending.
- 06
The regulator before the first cohort.
For a bank the card processor is a material outsourcing under PRA SS2/21 and FCA SYSC 8, so the PRA and FCA are notified before the arrangement changes, not after. The message to any customer who is reissued or must set up a wallet again is a Consumer Duty communication, tested for understanding before it is sent. Both are gates in the plan, with dates.
- 07
Nine months, and month one.
Nine months is credible for a staged move with no reissue; a reissued cohort adds plastic lead times. Three decisions gate month one: who holds the BIN and on what terms the sponsor lets it move; the incumbent's exit terms, notice period and data return; and the scheme calendar, because certification windows do not move for a cutover date. Those three set the date, not the project plan.
- 08
The build before any card moves.
Dual running works only if card preferences, limits, balance and fraud are decided on your side, behind one authorisation interface, the processor as transport. On a vendor hosted core where the processor decides those, that interface is a build in its own right, delivered first, incumbent still live. It reshapes the nine months and is priced first.
- 09
Rollback after a cohort has transacted.
A runbook reverses a cohort in its first hours only. Once it has transacted there, state has diverged: new authorisations, PIN changes, limits, lost and stolen. Rollback means syncing that state back to the incumbent before routing returns, and a routing change at the scheme takes days, not minutes. Each cohort has a rollback window and a point past which it is forward only.
- 10
Who leads it.
The engineer who implemented Thredd at Shaype, named above, leads the engagement, with a second named engineer in the code from week one and a cards lead on your side who owns the processor contract and the scheme relationship. The card stream is scoped to what one lead can run: staff cards first, then one range at a time, each watched and reconciled before the next, with no cutover night.
In the UK and EU
Faster Payments, Bacs and CHAPS in the UK; SEPA Credit Transfer and SEPA Instant in the EU; Open Banking payment initiation and variable recurring payments on both; card issuing through a processor on either side. Each has the shape of the rails we have built: a scheme rulebook, an authorisation or submission window, a return flow and a settlement file to reconcile against. NPP and PayTo are Australia's instant rail and its mandated payment scheme, broadly where Faster Payments and Open Banking variable recurring payments sit in the UK, and Direct Entry is broadly Bacs. The 93 ms figure was measured on Australian rails; the budget arithmetic is the same on yours.
The delivery path
Read the rulebook
Scheme rules, licence conditions and partner contracts set the constraints before a single interface is drawn.
Budget the latency
The time to a decision is divided between the checks before any of them is built, so no single one quietly spends the rest.
Integrate against the real thing
Sandbox parity, contract tests and replayable fixtures, so certification is a formality rather than a discovery phase.
Measure at the tail
p95 and p99 on real traffic, with alerts on the budget itself and not only on errors.
Card authorisation at Shaype, the Australian banking as a service platform operating under its own AFSL, built from 2018 to 2023 by the team our managing director, Marius Telespan, led as its Head of Engineering. The requirement was to authorise a card transaction within 200 ms of it reaching the API.
- Card preferences, limits by payment type (card present, card not present, Apple Pay and Google Pay, ATM cash), balance and fraud checks, all inside the window
- 93 ms at the 95th percentile, after performance work and a service architecture built for the authorisation path
- Card and account to account rails through one decision path
Bring us your payment orchestration problem
Ninety minutes with the engineers who would do the work, on one problem you name: a processor replacement, an onboarding flow, a ledger reconciliation.