That pending charge that later changes or disappears is a hold. In Rigid's ledger, an authorization places a hold, and clearing either captures it or releases it. Each step is its own timestamped entry, so a balance is always the sum of things that actually happened.
Endpoint down for a deploy? Rigid webhooks are signed with HMAC-SHA256, with secret rotation built in. Failed deliveries retry at 1m, 5m, 30m, 2h and 24h, and any event can be redelivered with one click from the console. https://t.co/4K1QMQzemt
Lost your card? On card programmes running on Rigid, freeze, revoke and reissue are instant from the banking app, and the replacement card is tokenized to Apple Pay or Google Pay in the same motion. Your phone is ready to tap again before you finish retracing your steps.
Card issuing has three roles. The programme manager owns the product, cardholders and first-line risk. The issuer or sponsor holds the licence and scheme membership. The processor runs authorization, clearing, the ledger and disputes. That's Rigid. https://t.co/KZrddBv3wP
From tap to balanced books in one pass. The network routes the authorization to Rigid, card state, controls, velocity and funding are checked together, Fraud AI scores it in 18ms, the double entry posts and a signed webhook reaches your systems. Same transaction, no batch.
Most card disputes start with a charge nobody expected. A disposable virtual card heads that off. One that dies after one payment, or stops at a cap, has nothing left to bill. Card programmes on Rigid can create them, so disputes are prevented, not fought after the fact.
When issuing, fraud, ledger and KYC live in separate systems, someone ends up reconciling the gaps. Rigid runs card issuing, authorization, fraud, ledger, KYC and programme management on one platform with one data model, so nothing falls between the pieces.
Our API reference and the machine-readable OpenAPI spec are generated from the same contract the platform is built against, so the docs and the API can't disagree. Plain REST over HTTPS, bearer tokens, idempotency keys, JSON. Start here https://t.co/UWgSOI38ul
Shopping online usually means giving every checkout your real card number. A disposable virtual card flips that. Each purchase gets its own number that closes itself once the charge clears, so your real card details never reach the merchant. Neobanks on Rigid can offer it.
Not every buyer is a person. A car paying for its own charge, a device buying data, a workload buying compute.
On Rigid, each can get a virtual card under a signed mandate a human set, with a cap, budget and expiry checked at authorization, plus a ledger entry per purchase.
Adding credit or BNPL next to a debit card shouldn't need a second stack.
On Rigid, debit, prepaid and credit account ranges on Visa and Mastercard run on the same rails, with Fraud AI that sees the whole programme, not one card at a time.
https://t.co/VU5RCo0GCl
Paying a freelancer for a two-week job shouldn't mean lending out the company card.
Card programmes running on Rigid can give contractors their own capped, time-boxed virtual card in their phone wallet. When the project ends, so does the card.
Running card programmes for many clients? On Rigid each programme is its own object with its own rules, ledger and flows, all in one console and one API. Every programme's books roll up into one trial balance, with a drill-down to a single card's history to the cent.
Switching card processors doesn't have to be one big cutover. In Rigid's gateway mode your core keeps the ledger and the approve or decline logic, while Rigid takes over the network side. Swap that first, move the books later, or never. https://t.co/fPYcBCYyK6
Making an insurance or warranty claim? Picture the payout as a virtual card that only works at repair shops, capped at the claim amount. You get the fix paid, the insurer gets a charge it can match to the claim. Card programmes running on Rigid can create cards like that by API.
Some shops still run older versions of the card security check at checkout. That shouldn't be your problem. Card programmes on Rigid handle EMV 3-D Secure 2.2 and 2.3 with graceful downgrade, so those merchants still authenticate and you never see an error page.
New card product, new market, new rules. On Rigid, that is configuration, never a reissuing project. Programmes are native objects you run from one console and one API, with organisations keeping teams apart, scoped roles and a tamper-evident audit trail. https://t.co/VU5RCo0GCl
Models or rules? With Rigid Fraud AI you get both. Adaptive models score every authorization in 18ms, and hard limits, geo-blocks and merchant-category policies run alongside them, tuned per programme without a deploy. Rules where you want them.
Three calls from zero to a first card. POST /v1/oauth/token, POST /v1/cardholders, POST /v1/cards. Plain REST with bearer tokens and Idempotency-Key, no client library required and nothing to keep up to date. A fourth, POST /v1/simulated-spends, runs a test authorization. https://t.co/DP76ZbzR4P
A first card for your teenager shouldn't work at a casino. Neobanks running cards on Rigid can give each family member their own virtual card, with merchant categories blocked, spending caps set, and an instant freeze in the parent's hands.