Guides, comparisons, compliance material and answers — written for the person who has to explain this platform internally, not for a search engine.
Comparison pages are usually written to win. These are written so you can work out quickly whether we are the wrong answer — which saves both of us a quarter.
Marqeta is a processor-led platform with its own issuing infrastructure. NDDEO is a product layer that runs on the processor you already chose. Where each makes sense, and where the overlap genuinely is.
ComparisonThredd supplies processing at scale. The question is what you build on top of it. A side-by-side of the work that remains after a Thredd integration, with and without NDDEO.
ComparisonBoth are frequently on the same shortlist and they answer different questions. This sets out which parts of a programme each one actually delivers.
ExplainerThe single most common source of confusion in a card procurement. What a processor does, what a card management system does, and why buying one does not give you the other.
GuideThe full sequence: licence, sponsor, processor, bureau, product layer, testing, go-live. What runs in parallel, what genuinely blocks, and where the time actually goes.
GuideWritten for teams in the month after authorisation. The decisions that set your time to market, and the ones that quietly set your cost base for the next three years.
These are available on request while the public library is being built. Ask for any of them and we will send the current version.
Written for the operations and engineering teams who will use this daily, once a decision has been made.
BIN, currency, limits, MCC set, fee schedule and artwork — the definition that everything else inherits from.
GuideWhen to use pockets, when to use child wallets, and how limits resolve when both apply to one transaction.
GuideWhat arrives nightly, how matching works, how to work an exception queue, and what finance receives at the end.
GuideWhich actions to put behind dual approval, how to set thresholds, and how to avoid blocking your own operations team.
GuideThe scenario list we recommend before go-live: declines, partial settlements, reversals, velocity breaches and FX.
ReferenceEndpoints, payloads, error codes, idempotency and retry behaviour. Full documentation is issued with sandbox access.
Your sponsor bank, your auditor and your regulator will each ask a version of the same questions. Here is where we stand on each.
The platform is built to PCI-DSS control expectations. Cardholder data is tokenised, PAN is never exposed to your application, and access to the card data environment is segregated and logged. Control documentation is available under NDA.
Data minimisation, purpose limitation, retention policy and subject-access export are part of the data model. We act as processor to your controller, with a DPA and a documented sub-processor list.
Strong customer authentication flows, exemption handling and transaction-data transparency consistent with PSD2 expectations of an issuer-side platform.
Client money is held in its own ledger with its own reporting, so the safeguarding position can be evidenced as a report rather than reconstructed during an audit.
Each client is a hard-isolated tenant. There is no shared ledger, no shared card data and no cross-tenant query path — enforced by construction rather than by a filter.
Architecture diagrams, data-flow maps, control descriptions, audit-log samples and our incident process, supplied for onboarding and periodic review.
Engineering months, ongoing maintenance, compliance overhead and the opportunity cost of the features that never got built.
WhitepaperLedger design, FX posting, pocket resolution during authorisation, and the reconciliation model that keeps it all provable.
WhitepaperWhat the first eighteen months after authorisation cost under each route to market, and which decisions dominate the outcome.
Short pieces on things that went wrong in production, and what we changed because of them.
A small discrepancy is almost always a structural problem wearing a small number. How to read one properly.
Dual approval fails when it is applied evenly. Which actions genuinely need it, and which just create a queue.
Three structures that keep appearing across payroll, family and corporate programmes, and one that never works.
If yours is not here, ask it — the answer usually gets added.
Neither, and deliberately so. We supply the product layer that sits above your bank, BIN sponsor and processor: card management, wallets, ledger, compliance controls and settlement. You contract your infrastructure directly, on your own paper.
This is not a limitation we are working around. It is the model — it means we can be recommended by processors and sponsors without ever becoming their competitor.
Yes. NDDEO is a technology provider, not a licensed institution. You need the relevant permission — EMI, PI, MSB, banking licence or equivalent — along with a BIN sponsor and a processor. If you are earlier than that, we can talk you through the sequence, but we cannot substitute for it.
Weeks rather than quarters, once sponsor and processor connectivity is in place. The platform work is configuration rather than engineering, so the critical path is usually your counterparties and your own testing, not us.
The honest caveat: if your sponsor or processor integration is not yet agreed, that is the timeline, and no platform can compress it.
Yes, end to end. Your brand on the card, the app, the operations console, the statements and the notifications. There is no NDDEO logo anywhere your customer or your client can see, and no reference to us in any customer-facing artefact.
Yes. One tenant can hold several BINs, several sponsors and several card products across regions, each with its own rules and reporting but reconciling through one ledger and one audit trail.
It is yours. Card, wallet, ledger and transaction data is exported in full on exit, in a documented format, along with the audit trail. Exit assistance terms are written into the agreement rather than negotiated at the point you want to go.
Yes, and we would rather you did. Sandbox access is free during evaluation and includes processor simulation, so you can run declines, partial settlements, reversals, velocity breaches and FX scenarios against your own test cases instead of watching a scripted demo.
Your team, in your branded console, under your own roles and approval rules. We operate the platform underneath — hosting, security, releases and support — but card operations stay with you, which is what your licence conditions generally require.
A setup fee, a monthly platform fee, a per-active-card fee and a per-transaction fee. That is the whole model. We do not take a cut of your interchange and we do not mark up your processor or sponsor costs. See how pricing works.
Email support at business hours on Starter, a named account manager and priority response on Growth, and 24/7 cover with agreed response times on Enterprise. Platform releases, security patching and maintenance are included at every tier.
A 45-minute architecture review: your licence, your BIN sponsor, your processor — and exactly what NDDEO would run on top.
