See FinVeil in 10 steps

FinVeil is a payments orchestration layer built in South Africa. It has adapters for six providers — Stitch, Paystack, Yoco, PayFast, Ozow and Rapyd. The routing engine scores each eligible provider and rail on speed, cost, reliability and bank match, selects one, and records the decision. FinVeil has not processed live customer volume yet.

• •Paystack is verified end to end in test mode. Yoco and PayFast run against sandbox credentials.
• •Ozow and Stitch (PayShap, RTC, SDV, Instant EFT) adapters are built but not yet connected. Rapyd is sandbox-only and excluded from production.
• •One API in front of them — your integration stays the same regardless of which provider handles the payment

Split payments: Paystack settles each party's share directly to that party's Paystack subaccount. Other collections (payment links without a split, /api/payments and /v1 collections) settle into FinVeil's Paystack merchant balance, and Paystack debits refunds and chargebacks from that balance. See our architecture and security posture.

When a transaction is routed, FinVeil's router evaluates every eligible provider and rail. It scores each option across four dimensions, weighted by routing mode:

• •Speed score (weight 50% for instant payouts): PayShap = 100, RTC = 90, Instant EFT = 85, SDV = 60, Card = 50, EFT = 20
• •Cost score (weight 20% for instant, 60% for cheapest mode): cheapest sourced rate scores 100, most expensive scores 0; a rate we cannot source scores 0
• •Reliability score (weight 20%): 24-hour success rate per provider; a provider with no track record scores 70
• •Bank match score (weight 10%): a PayShap proxy recipient on a PayShap-capable provider scores 100

The weighting follows the routing mode: "instant" prioritises speed, "cheapest" prioritises cost, "same_day" balances them. Speed scores describe the rail, not a settlement time FinVeil has measured.

Every routing decision records a fallback order. In test mode, FinVeil can walk that order against simulated provider outcomes. For real money, automatic failover is deliberately off: a failed live transaction is retried on the same provider, because re-sending money to a second provider risks a double charge. Automatic live failover is on the roadmap.

• •Test mode: a retryable simulated failure moves to the next option in the fallback order
• •A terminal error (invalid account, insufficient KYC) never fails over
• •The fallback order is stored with the routing decision

In the demo, the R1,200 transaction shows a simulated failover from Stitch to Paystack. It is sample data, not a real transaction.

This is the screen your operations team would work in. Every transaction — amount, provider chosen, rail used, current state. Filterable, and every row is clickable for the full story. The demo uses simulated data.

Click any row to open the detail drawer with routing decision and ledger proof.

Inside each transaction, the Routing Decision panel shows every provider that was considered, their individual scores across all four dimensions, and exactly why the winner was selected. This is full transparency — no black box.

• •See every provider×rail option that was scored
• •Winner highlighted with the highest total score
• •Ineligible providers shown with the reason (credentials not set, provider down, etc.)
• •Inputs shown: amount, currency, routing mode, recipient type

The demo transactions are simulated. Click any of them to see how each option scored.

Every settled transaction posts balanced double-entry accounting records. DEBIT and CREDIT, with human-readable account labels ("MERCHANT CASH", "PROVIDER PAYABLE"), summing to balanced. The ledger records provider outcomes; it does not hold money.

• •A posting whose debits do not equal its credits is refused by the application
• •Account labels resolve to human-readable names, not raw UUIDs
• •A nightly job recomputes cached account balances from the ledger entries
• •Every cent is traceable from API request → routing decision → ledger entry

In any transaction drawer, scroll past routing to see "Ledger Proof" with the balance check.

The cost score comes from provider rate cards. Each rate card records its source and whether FinVeil has verified the rate. A rate FinVeil cannot source is not quoted and scores 0 on cost, so an unknown rate never looks cheapest.

• •Verified example: Paystack checkout collections at 2.9% + R1 plus VAT, matched to the cent on real test-mode charges
• •Unverified rates (including Stitch PayShap, RTC and SDV) are shown as unverified and not quoted

FinVeil's own rail fees are on the pricing page. They are separate from what the provider charges.

Two billing models: a flat subscription tier with a metered API-call quota, or pure per-transaction pricing with no subscription (the reseller model). Sandbox is R0. Pilots start at R75,000 for a 30-day discovery.

• •Starter: R3,500/month, up to 10,000 API calls (R0.35 per additional call)
• •Growth: R12,500/month, up to 50,000 API calls
• •Scale: R35,000/month, up to 200,000 API calls
• •Enterprise: custom pricing

Ready to evaluate FinVeil for your business? A 30-day Discovery & Tinker phase gives you a test-mode account on the real API, with Paystack verified end to end in test mode, and a clear go/no-go. No production money moves until you're ready.