Meet us at conferences around the world
SBC Summit Lisbon
SiGMA Europe
Adding a second payment provider should not require a second checkout. Yet that is often where the work ends up: a new provider brings different request fields, customer steps and response codes, and the application has to accommodate them all.
Payment orchestration API integration connects an existing checkout to the payment providers configured for a business. Your application starts the payment and manages the customer journey, while Payneteasy Payment Orchestration processes the request according to the configured channels and routing rules.
The integration boundary matters: a successful initial API response is not necessarily a completed payment. Your application must handle the final result through the applicable callback or status flow before marking an order as paid. Adding a provider also requires checking its availability, configuration and payment flow before offering it to customers.
Before writing code, decide which system owns each part of the payment journey.
| Responsibility | Your application | Payneteasy Payment Orchestration |
|---|---|---|
| Payment options shown to the customer | Presents the options agreed for your markets and checkout flow | Connects the payment channels configured for your setup |
| Order and customer experience | Creates the order and manages the checkout screen | Processes the payment request |
| Provider selection | Supplies the transaction details required by the integration | Applies the configured routing rules |
| Final result | Updates the order and tells the customer what happened | Provides the transaction result through the applicable callback or status flow |
This boundary keeps your product in control of its customer experience while provider connections and routing are managed in the payment infrastructure. It also exposes a common integration mistake: showing a payment option in checkout before confirming that the corresponding channel is configured for the customer's country, currency and transaction type.
The first approved test transaction proves that an API call works. It does not prove that the checkout handles the situations customers will encounter in production.
For each payment flow, your implementation needs to:
Design the order state for payments that remain in progress, customers who close a page and results that arrive after the browser session ends. The application should not mark an order as paid merely because the initial request returned successfully.
The Payneteasy API documentation describes the available payment flows, callbacks and status requests. Choose the use case that matches the method you intend to launch, then test its complete journey.
Payneteasy maintains more than 1,000 payment integrations across providers, payment methods and platforms. That describes the range of available connections. It does not mean every integration is a PSP or that every option is active for every customer.
Start with a defined set of requirements: the countries and currencies you serve, the transaction types you need, and the providers you have arranged to use. Confirm which channels are available for that setup before adding their methods to your checkout.
When you add a provider later, check whether its payment flow requires a different customer step or additional information. A shared API can reduce repeated provider integration work, but method-specific requirements still need development and testing where they apply.
Connecting multiple providers gives your business more possible routes. Routing rules decide which connected route receives a transaction. Cascading can provide another attempt when the configured conditions permit it.
Those rules should reflect the payments you actually process. A decline caused by a temporary provider issue is different from one that should not be retried. Before enabling an alternative route, decide which transaction outcomes qualify, whether the next provider supports the same flow and how your application will display the final result.
Your checkout should receive a dependable transaction outcome without having to reproduce the provider-selection logic in its own code. Your payment team should still be able to review which route was used and whether the configured rules behaved as intended.
An API connection alone does not determine whether raw card data enters your application. That depends on the checkout design.
If you need card inputs within your branded page, Payneteasy Hosted Fields places the sensitive fields in Payneteasy-served iframes. Your page and backend receive a token for the payment request instead of the raw card number and CVV. This can reduce PCI DSS scope, but the applicable requirements must be assessed for the complete implementation.
Make this decision before finalising the frontend and backend flow. Changing card-data handling late in development can affect both.
Run sandbox tests for the states your application will have to explain to a customer and reconcile internally:
For each case, check the internal order, the status shown to the customer and the transaction information available to your payment team.
Payneteasy publishes its Processing API as an OpenAPI 3.1 specification. Engineers can use the machine-readable contract to inspect operations and generate client code. The specification supports implementation; the selected payment flows, provider configuration and end-to-end tests determine whether the integration is ready.
| Direct-to-PSP integration | Cashier integration API (Payneteasy) | |
|---|---|---|
| Engineering effort per new PSP | Full custom build: auth, webhooks, error mapping | Routing configuration against an existing spec |
| Typical time to add a PSP | Weeks to months, provider-dependent | 1-2 weeks |
| Failover between providers | Requires custom logic per pair of PSPs | Smart routing/cascading built into the layer |
| Spec format | Varies by provider, often proprietary | OpenAPI 3.1, machine-readable |
| AI-agent observability | Not standardized; typically none | Read-only MCP server, zero write path |
| Merchant account / settlement risk | Depends on provider relationship | Payneteasy does not hold merchant funds or settlement risk — it is a technology and orchestration layer, not a payment facilitator |
The path from a signed integration to a working cashier follows the same shape regardless of how many PSPs a platform eventually connects:
Yes. Your application can continue to own the checkout experience while connecting its payment requests to Payneteasy Payment Orchestration. The integration still needs to account for the customer steps required by each selected method.
No. One integration provides a common technical connection. The providers and methods your business can use depend on its configured channels, markets, currencies, transaction types and provider arrangements.
No. Another attempt depends on the transaction outcome and the cascading rules configured for the available routes. Retrying every decline would be an incorrect payment strategy.
Thank you for reaching us. Your request has been sent successfully. We will get back to you as soon as possible.
Message was not sent
