One API, many processors
Create, capture, refund and void through one API. Finyst translates each call for the processor that takes it.
Finyst sends each payment to the processor most likely to approve it, retries soft declines on the next best route, and reconciles it all against one ledger. Saved cards stay portable, so you are never locked to one processor.
Illustrative test-mode traffic. Switch strategy, click a processor to take it offline, or press P to send a payment.
One integration for the processors and payment methods your customers already use
The problem
Different SDKs, webhook formats, decline codes and settlement files. Each one works in isolation, and none of them helps the others when a payment fails.
Integration backlogengineer-weeks
Illustrative estimates for a typical in-house build.
The routing layer
Seven building blocks that turn a pile of processor accounts into one payment system you can reason about.
Create, capture, refund and void through one API. Finyst translates each call for the processor that takes it.
One SDK for web and mobile that shows the right methods for each customer.
Frictionless where issuers allow it, challenge where risk or regulation calls for it.
Frictionlessrisk 12 / 100
Refund on any processor from one screen. Disputes arrive with deadlines and evidence slots.
dp_2291Product not received6 days left
dp_2287Fraudulent · 10.4Evidence sent
re_8812Refund · $24.00Settled
Store a card once, then charge it on any connected processor with the same token.
Authorisation, decline reasons, latency and cost for every processor on the same axes, down to network and country.
Where your processors support them, card-scheme tokens keep saved cards working after a reissue, and can lift approval on repeat payments.
Intelligent routing
Pick a strategy, move the sliders, flip the rules. The flow and the projected approval and fees update as you go.
Write explicit rules on network, amount, currency, country or method. First match wins.
else cards → Stripe · wallets → Braintree
Compared with one card processor plus PayPal. Illustrative rates and fees for a fictional merchant.
{
"algorithm": "rules",
"rules": [
{
"if": "card_network = amex && amount > 50000",
"then": "adyen"
},
{
"if": "currency = INR",
"then": "razorpay"
},
{
"if": "payment_method_type = paypal",
"then": "paypal"
}
],
"default": {
"card": "stripe",
"wallet": "braintree"
}
}Automatic failover
Finyst watches error rates and latency on every connector. When one breaks its threshold, the circuit opens, traffic moves to the next best route and soft declines are retried there. Take one down yourself.
With FinystPinned to one route
Event logUTC
Health checks passing on 4 connectors
Routing rules v14 published by m.okafor
Runs its own drill until you take over. Illustrative traffic, thresholds and figures.
Health is scored per connector, so failover happens before anyone opens a dashboard.
A restored processor comes back at a fraction of its share and earns the rest.
Circuit changes post to your alerting and land in the audit log.
Life of a payment
From the first connector to the last settlement line, every payment keeps its full history.
Add each processor's credentials once. Finyst checks them, pulls supported methods and turns each account into a connector you can route to.
Connectors · acme
Rules, volume splits, success rate or cost decide the first attempt. Every version of every rule is kept, so you can see which one moved a payment.
Rule set · checkout-live · v14
payment
wallet = paypal→PayPal
amex and amount > $500→Adyen
currency in EUR, GBP→Checkout.com
else→Stripe 60 · Braintree 40
Published by m.okafor · diff against v13 · rollback in one click
One call carries the payment through 3DS when needed, to the chosen processor, and back with a normalised status in a few hundred milliseconds.
pay_Q7f3a91c20 · $65.40
A soft decline or a timeout is retried on the next best route. Hard declines like stolen cards are never retried, so issuers keep trusting you.
Attempts · pay_Q7f3a91c20
Hard declines (stolen, lost, insufficient funds) are never retried.
Settlement files from every processor land in one ledger, matched to your orders, with fees, refunds and chargebacks broken out.
Settlement · Sep 24
3 lines need review · $41,212.08 net settled · illustrative
Vault and tokenisation
The card number goes into the Finyst vault and comes out as a token. Every processor can charge that token, and card-scheme network tokens keep it working when the plastic changes.
Waiting for a card.
Finyst vaultPCI DSS scope · contained
Reuse the tokenstored once · used 0×
Same customer, three processors, no re-collection. Switching processors later does not strand your saved cards.
Recovered revenue
A customer who reached the pay button wanted to buy. Put in your own volume and decline rate and switch on the levers Finyst gives you.
$1,721,856 a year · about 2,759 orders a month at a $52 basket
Illustrative model, not a forecast. Assumes 60% of declines are soft and effects that vary a lot by business, region and card mix.
Reconciliation
Settlement lines from every processor are matched to your orders automatically. Only the exceptions reach a person, with the context to resolve them.
Illustrative settlement data for a fictional merchant. Open a flagged line to resolve it.
For developers
Create a payment the same way whoever ends up taking it. Idempotency, retries and webhooks behave identically on every connector.
create-payment.sh
curl https://finyst.techyst.net/api/payments \
-H "api-key: $FINYST_SECRET_KEY" \
-H "Idempotency-Key: ord_10421" \
-H "Content-Type: application/json" \
-d '{
"amount": 6540,
"currency": "USD",
"confirm": true,
"customer_id": "cus_acme_8812",
"payment_method": "card",
"payment_token": "tok_9f3a2c71e0b4",
"profile_id": "checkout-live"
}'checkout.ts
// Plain fetch against the Finyst payments API
const res = await fetch("https://finyst.techyst.net/api/payments", {
method: "POST",
headers: {
"api-key": process.env.FINYST_SECRET_KEY,
"Idempotency-Key": "ord_10421",
"Content-Type": "application/json",
},
body: JSON.stringify({
amount: 6540, // minor units
currency: "USD",
confirm: true,
customer_id: "cus_acme_8812",
payment_method: "card",
payment_token: "tok_9f3a2c71e0b4",
profile_id: "checkout-live",
}),
});
const payment = await res.json();
console.log(payment.status, payment.connector, payment.attempt_count);
// succeeded adyen 2checkout.py
import os
import requests
res = requests.post(
"https://finyst.techyst.net/api/payments",
headers={
"api-key": os.environ["FINYST_SECRET_KEY"],
"Idempotency-Key": "ord_10421",
},
json={
"amount": 6540, # minor units
"currency": "USD",
"confirm": True,
"customer_id": "cus_acme_8812",
"payment_method": "card",
"payment_token": "tok_9f3a2c71e0b4",
"profile_id": "checkout-live",
},
timeout=10,
)
payment = res.json()
print(payment["status"], payment["connector"], payment["attempt_count"])
# succeeded adyen 2Checkout.java
import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
var body = """
{"amount": 6540, "currency": "USD", "confirm": true,
"customer_id": "cus_acme_8812", "payment_method": "card",
"payment_token": "tok_9f3a2c71e0b4", "profile_id": "checkout-live"}
""";
var request = HttpRequest.newBuilder(URI.create("https://finyst.techyst.net/api/payments"))
.header("api-key", System.getenv("FINYST_SECRET_KEY"))
.header("Idempotency-Key", "ord_10421")
.header("Content-Type", "application/json")
.POST(HttpRequest.BodyPublishers.ofString(body))
.build();
var response = HttpClient.newHttpClient()
.send(request, HttpResponse.BodyHandlers.ofString());
System.out.println(response.body());
// {"status":"succeeded","connector":"adyen","attempt_count":2, ...}Press “Send request” to replay one payment through the router. Sandbox data only.
The difference
A single processor is simple until it declines, goes down or reprices. Stitching several together by hand means a new integration every time. Finyst gives you one routing layer across all of them.
Control and security
Card data enters the vault and never touches your application servers or logs, so the systems in PCI DSS scope stay few and well defined.
Card data is encrypted at rest with rotating keys and replaced by tokens everywhere else. The vault keeps PCI DSS scope contained.
Rule edits, refunds, key rotations and dashboard sign-ins are recorded with who, what and when.
Separate roles for engineering, finance, support and admins, with refund limits per role and sign-in through your identity provider.
Every event carries an HMAC signature so your services can verify it came from your Finyst before acting on it.
Payments, refunds, disputes and settlement lines export to CSV or your warehouse on a schedule, with the rule version that routed each one.
Webhooks
Each webhook is signed with a secret only your services and your Finyst know. Verify it in a few lines, then act.
webhooks.ts
// Verify a Finyst webhook before acting on it
import { createHmac, timingSafeEqual } from "node:crypto";
export function verify(rawBody, header, secret) {
const expected = createHmac("sha512", secret).update(rawBody).digest("hex");
return timingSafeEqual(Buffer.from(expected), Buffer.from(header));
}
// header: x-webhook-signature-512
// event: payment_succeeded · pay_Q7f3a91c20 · adyen · attempt 2FAQ
Payments carry real risk, so here are straight answers. If yours isn't here, write to us and an engineer who works on Finyst will reply.
No. You keep your processor contracts and merchant accounts. Finyst sits in front of them, decides which one takes each payment, and retries on another when that helps.
The major card processors and acquirers, the big wallets and a long list of local methods, from iDEAL and SEPA to UPI and Pix. Coverage varies by country and method, so we confirm your exact list before kickoff and add new connectors as you need them.
No product can promise that on its own. Finyst keeps raw card data inside the vault, so your application servers only ever handle tokens. That keeps PCI DSS scope contained to a small, well-defined boundary. Your own assessment still applies, and we help you document the boundary for it.
Finyst doesn't take a cut of each payment, so your costs don't climb with volume. Your processors still charge their own fees. Ask us for a quote.
Finyst is built for high availability, with redundancy, continuous health checks, alerting and changes rolled out gradually. We agree an on-call and escalation path with you before go-live, and your team gets status updates the moment anything changes.
Roles separate engineering, finance, support and admins. Refund limits are set per role, rule changes can require a second approver, and sign-in goes through your identity provider with SSO. Every action lands in the audit log.
Many processors will export stored card data to another PCI-compliant vault on request. We plan that migration with you, import them into the Finyst vault, and keep the old processor running until the move is verified.
One API and one set of SDKs for web and mobile, in sandbox first. We set up your account, connect your processors and run test traffic with your team before a single live payment goes through.

Connect your processors once, set the rules you want, and watch declines turn into recovered revenue, with every payment on one ledger.