Platform capability
One integration, every provider behind it
Build against Peneu once. After that, adding, switching or removing a payment provider is a configuration change, not another integration project.
- One API for payments, refunds and status
- One signed webhook format
- One set of keys per environment
Before: your system maintains four separate integrations, one per payment provider, each with its own SDK, status codes and callbacks. After: one integration to Peneu, which connects to the same four providers.
The work
What you'd build for each provider, and what you build once
A direct integration isn't just “create payment”. This is the list teams underestimate.
For every provider, without orchestration
- Authentication and request signing
- Payment creation, plus redirect, intent or SDK handling
- Status polling and callback verification
- Refunds and partial refunds
- Mapping the provider's error codes
- Parsing its settlement file for reconciliation
- Tests, certification, and upgrades when its API changes
Once, with Peneu
- One API key per environment
- One payment object and status model
- One signed webhook format
- One refund call, whichever provider took the payment
- One error model, with the provider's raw code kept
- Reconciliation across providers in one place
What integrating involves
From sandbox to live
- 01
Get sandbox keys
Test keys for a sandbox where you can run every flow (success, failure, refund, webhook) without moving real money.
- 02
Create payments from your backend
Your server creates a payment with an amount, a method and your order reference, then hands the customer to the checkout step the method needs: a UPI intent, a card authentication page or a bank redirect.
- 03
Handle one set of webhooks
Verify the signature, update the order and respond quickly. The same handler works whichever provider processed the payment.
- 04
Go live one provider at a time
Your providers are connected on Peneu's side. Turning a provider on, or giving it a share of traffic, doesn't touch your code.
The integration
What your code looks like
- The same three pieces whether one provider is behind Peneu or five
- Illustrative. The full reference is shared with sandbox access
curl -X POST https://api.peneu.com/v1/payments \
-H "Authorization: Bearer $PENEU_API_KEY" \
-H "Idempotency-Key: order-10234-1" \
-d '{
"amount": 149900,
"currency": "INR",
"method": "upi",
"reference_id": "order-10234",
"customer": { "email": "[email protected]" }
}'{
"id": "pay_7Hq2",
"status": "processing",
"reference_id": "order-10234",
"provider": "provider_a",
"next_action": {
"type": "upi_intent",
"url": "upi://pay?pa=...&am=1499.00"
}
}app.post("/webhooks/peneu", express.raw({ type: "*/*" }), (req, res) => {
const event = verifyPeneuSignature(req.body, req.headers, WEBHOOK_SECRET);
if (!event) return res.sendStatus(400);
if (event.type === "payment.authorized") {
markOrderPaid(event.data.reference_id, event.data.id);
}
res.sendStatus(200); // respond fast; do slow work async
});Afterwards
What changes when your provider mix changes
| Change | Your code | In Peneu |
|---|---|---|
| Add Provider D for cards | No change | Connect D and enable it for cards |
| Move UPI from Provider A to Provider B | No change | Update routing |
| Offer a new method an existing provider supports | Add it to your checkout options | Enable the method |
| Stop using a provider | No change | Disable it. Refunds on its old payments still go back to it |
Worth knowing
What one integration doesn't replace
Provider onboarding still applies. Each provider runs its own merchant checks and agreement before it can process your payments. Peneu takes care of the technical connection and tells you what each provider needs.
Checkout steps still depend on the method. UPI needs an app switch or a QR, cards need authentication, and netbanking redirects to the bank. The API gives you one way to handle all of them, and your UI still has to show them.
Evaluating it
Questions to ask about this, of any provider
Use these with any platform, including Peneu. For Peneu, what's available for your business is confirmed during onboarding.
- Which providers and methods sit behind the one integration for my business?
- The value of one integration depends on what it reaches. Ask for the list that applies to you, not the general one.
- What happens when a provider changes its API?
- Someone has to absorb the change. Ask who does, and how you're told.
- Can I still reach provider-specific features?
- Some features exist on one provider only. Check how the integration exposes them, if at all.
- How do I test failures, not just successes?
- A sandbox that can simulate declines, timeouts and duplicate notices is worth more than a polished happy path.
FAQ
Questions about one integration
How is this different from integrating a payment aggregator?
An aggregator gives you one integration to one provider's services. Peneu gives you one integration to several providers, including aggregators, gateways and acquiring banks, with routing, retry and failover between them.
Do I need to remove my existing provider integration first?
No. Many teams move one method or one share of traffic to Peneu first, keep the existing integration running, and move the rest once the numbers look right.
Which languages can I integrate from?
Any language that can make HTTPS requests and verify an HMAC signature. The examples on this site use cURL and Node.js.
Is there a sandbox?
Yes. Sandbox access comes with test keys and the full API reference. Request it from the developers page.
Works together with
- Unified APIOne request & status modelView details
- Unified WebhooksOne normalised event streamView details
- Multiple Payment ProvidersGateways, aggregators & acquiring banksView details
- Reconciliation & ReportingMatch payments & settlements across providersView details
Related products
Start with one method
Most teams begin by moving one payment method, or a share of their traffic, onto Peneu. We'll help you pick the one that's the least risky and teaches you the most.
Last reviewed . Samples on this page are illustrative.