Developers
No extra integration. Orchestration is built in.
LumniPay runs inside Tagada. You build with Tagada's APIs, webhooks and checkout, and LumniPay routing, cascades and risk rules apply to every payment automatically.
One integration
Your store and funnels connect to Tagada once. There is no second SDK, API key set or checkout to maintain for LumniPay.
Events you can act on
Payment outcomes reach your systems through Tagada webhooks, so fulfilment, CRM and analytics stay in sync with what was actually approved.
Configuration, not code
Routing rules, cascades, splits and caps are configured in the dashboard. Changing a rule never requires a deploy.
Webhooks
Build handlers that survive real traffic.
Payment systems are asynchronous and retry deliveries. A few habits keep your integration correct under load.
- Verify the signature of every webhook before trusting it
- Make handlers idempotent: the same event may arrive twice
- Respond quickly, then do heavy work in a background job
- Fulfil on confirmed payment events, not on browser redirects
- Store decline codes: they explain approval rate changes later
// Example webhook handler (Node.js).
// Payload shape is illustrative: refer to Tagada's developer docs for the exact schema.
app.post("/webhooks/payments", verifySignature, async (req, res) => {
const event = req.body;
// Webhooks can arrive more than once: make handlers idempotent.
if (await alreadyProcessed(event.id)) return res.sendStatus(200);
switch (event.type) {
case "payment.succeeded":
await fulfilOrder(event.data.order_id);
break;
case "payment.failed":
await flagForFollowUp(event.data.order_id, event.data.decline_code);
break;
}
await markProcessed(event.id);
res.sendStatus(200);
});{
"name": "US subscriptions",
"when": {
"country": ["US"],
"product_type": "subscription",
"card_brand": ["visa", "mastercard"]
},
"route": {
"strategy": "percentage",
"split": { "mid_a": 70, "mid_c": 30 },
"respect_caps": true
},
"on_soft_decline": {
"cascade_to": ["mid_b"],
"max_attempts": 2
}
}Routing as configuration
Rules your whole team can read.
Rules combine conditions (country, card brand, BIN, amount, product type) with a strategy (priority, percentage split, round-robin) and a fallback for soft declines. The example on the left is illustrative of how a rule is structured.
Testing
Test before you go live.
Use test mode
Run end-to-end orders in your Tagada test environment before enabling live processing, including upsells and subscription renewals.
Simulate declines
Check that your funnel handles declined, cascaded and approved outcomes, and that customers never see a duplicate charge.
Watch the first live days
Review approval rates and decline reasons per MID after launch, then adjust rules with real data rather than guesses.