Open source payment orchestration

The orchestrator must post settlement, fee and refund entries into the general ledger with the right accounts, tax treatment and period. The usual pattern is a scheduled export or API push from the orchestrator's transaction records into journal entries in the ERP, such as Odoo or ERPNext, rather than manual keying. Common failure points include mismatched chart of accounts codes between environments, currency rounding differences on multi-currency settlements, and timing gaps when a payout lands in a later period than the sale. Confirm with your finance team which entry types are posted, who approves exceptions, and how reversals of refunds and chargebacks are recorded. Ask an implementation partner to test a full month-end close against a copy of production data before go-live.

The order system is the source of truth for amount, currency, line items and payment state, so the orchestrator must receive those values without drift. Integration usually means an API call that creates a payment intent when an order is placed, webhooks that update order status on authorization, capture, failure or refund, and idempotency keys so a retried request does not charge a customer twice. Common failure points include orders that change value after authorization, partial shipments that need partial captures, and webhook events that arrive out of order. Ask your engineers to define a single status model shared by both systems and to document which system wins when they disagree.

Fraud tools usually sit in the authorization path, scoring a transaction before or after it is sent to a processor, and returning an accept, review or decline decision. The orchestrator needs to pass the right signals (device, velocity, billing and shipping data, customer history), receive the score within a latency budget, and route flagged payments to a review queue. Failure points include fraud rules that silently block a legitimate processor route, missing data fields that weaken scoring, and no fallback when the fraud service is unavailable. Confirm whether your fraud provider is inline or post-authorization, what happens on timeout, and who owns rule changes.

Yes. Administrators can change routing rules, rotate connector credentials and view card-adjacent data, so the admin console should authenticate through your corporate identity provider with multi-factor authentication and role-based access. The Safeguards Rule at 16 CFR 314.4 requires multi-factor authentication for any individual accessing an information system at covered financial institutions, and it requires activity logging for authorized users. Common failure points include local break-glass accounts that never get reviewed, service accounts with broad API keys, and role definitions that let one person both change routing and approve settlements. Ask for a list of every admin role, the connector secrets each one can read, and the approval workflow for routing changes.

The orchestrator should emit structured logs for authentication, configuration changes, routing decisions, connector errors and administrative actions, forwarded to your SIEM with consistent timestamps and transaction identifiers. These logs support incident response, fraud investigation and the activity logging expected under 16 CFR 314.4. Failure points include logs that omit the processor or routing rule that made a decision, card data accidentally written to log files, and retention shorter than your investigation or records policy. Confirm which events the platform logs by default, which need configuration, and how log integrity is protected. Test that a failed payment can be traced from the merchant order to the connector response inside your SIEM.

Most teams replicate transaction, refund, dispute and settlement tables from the orchestrator database, or consume its event stream, into a warehouse for authorization rate, cost and reconciliation reporting. The main design choices are whether to read from a replica to avoid load on the live database, how to handle late-arriving settlement files, and how to keep the warehouse copy of card-adjacent fields to the minimum needed. Common failure points include schema changes in the orchestrator upgrade breaking pipelines, duplicate rows from retried ingestion, and reports that mix gross and net amounts. Ask for the data dictionary and agree on one definition of a completed payment before building dashboards.

Kill Bill is an open source subscription billing and payments platform licensed under Apache-2.0, and it is relevant when recurring invoices, plan changes and dunning must be handled before payments reach the orchestrator. In that split, Kill Bill generates invoices and payment attempts, and the orchestrator routes them to processors and returns outcomes for retries and account updates. Failure points include two systems each running retry schedules, double charges when both trigger a retry, and inconsistent invoice states after a processor timeout. Decide early which system owns the retry policy and the customer's stored payment method, and confirm how each reports outcomes back to the other.

Cost follows the number of connectors, the routing and retry logic you need, the depth of tokenization and PCI scope work, and the reconciliation reporting your finance team expects. Hosting in your own cloud account or data center adds infrastructure and operations effort that recurs after launch. Ask each partner to split the quote into one-time items (discovery, configuration, integration, testing, documentation) and recurring items (upgrades, monitoring, support retainers). Platform licensing for Hyperswitch is Apache-2.0, so the open-source software itself carries no license fee, but processor contracts and your own staff time still apply.

No duration can be stated without the written scope, because timing depends on how many processors you connect, how many payment methods and markets you cover, and how quickly your team can supply credentials, test accounts and sign-off. A common approach is a phased rollout: one processor and one payment flow first, then added connectors, retry and routing rules, and finally reconciliation automation. Ask for a timeline tied to named phases, each with entry and exit criteria, and confirm which dependencies sit with your processors and internal approvers.

Expect to supply a named business owner for payment flows, a finance contact for reconciliation, an engineer who can manage cloud or data center access, and a security reviewer for PCI scope decisions. Your processors must provide sandbox and production credentials and documentation for their APIs and webhooks. Your team also needs to approve change management steps, since the FTC Safeguards Rule at 16 CFR 314.4 requires covered financial institutions to adopt change management procedures. Ask the partner to list these roles in the statement of work before work begins.

It can, if you have engineers who understand payment APIs, container and Kubernetes operations, secrets management, database backups and incident response for systems that touch cardholder data. The harder part is ongoing: keeping connectors current as processors change APIs, applying platform releases, and maintaining routing rules as acceptance rates shift. Assess this honestly by listing who would own each duty, how many hours per month that represents, and what happens during an outage at a processor. Many buyers split the work, keeping routing decisions in house and contracting upgrades and monitoring.

Compare quotes against the same written scope, not against headline totals. Each quote should name the processors and payment methods in scope, the routing and retry logic to be built, how tokenization and PCI scope will be documented, the reconciliation outputs, the test plan, and the handover documents. Check whether the partner plans, implements, hardens, backs up and documents the platform inside your environment, and whether they run security testing separately. Ask for fixed-scope deliverables with acceptance criteria, and for a clear change request process for anything added later. DeployOpen works from written, fixed scope and issues no price list, so a quote follows from that scope.

After launch the platform still needs routine work: applying Hyperswitch releases (v1.128.0 was the latest version at the time of writing, published October 16, 2026), updating connectors when processors change APIs, reviewing failed payment trends, and keeping backups and logs in order. Ask the partner whether they offer retainers for upgrades, monitoring and support, what response expectations they commit to in writing, and who handles incidents involving a processor. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, which you can scope separately from the initial build.

The orchestrator can produce audit logs of payment activity, configuration change records, and reconciliation reports that support your own controls. Its scope depends on whether card data passes through your systems or is handled by a vault or processor. The FTC Safeguards Rule at 16 CFR 314.4 requires encryption in transit and at rest, multi-factor authentication, change management, and logging of authorized user activity, and it calls for penetration testing and vulnerability assessments at least every six months unless continuous monitoring is in place. DeployOpen prepares systems, controls and evidence for assessments, but independent auditors issue any audit report or attestation.

DeployOpen plans, implements, integrates and documents self-hosted platforms inside your own infrastructure, and it prepares systems and evidence for compliance assessments. It does not issue certifications or attestations, and the scope decision for cardholder data should be confirmed with your qualified assessor and your acquiring banks. Ask the partner to map which components store, process or transmit card data, to recommend whether tokenization through a vault reduces that footprint, and to document the decision. DeployOpen also runs application and API security testing that can cover the orchestrator's interfaces.