One integration layer for every way you get paid.

Payment orchestration is a capability of Juno, 934's hospitality payments platform, that connects where a hotel accepts money to the rails that approve and move it. On one side are the points of interaction — the terminal at the desk, online checkout, Pay-by-Link, and charges raised inside the PMS or POS. On the other are the gateways, acquirers, card schemes and alternative methods that decide whether a payment is approved and later settle the funds. Orchestration routes each authorisation request, returns an approved or declined result, and records the transaction so that settlement, reconciliation and accounting have an accurate basis to work from. Accepting a payment and receiving the money are distinct events; orchestration governs acceptance and feeds settlement. It is the capability the Hospitality and Financial Suites build on.

Related: Juno Hospitality Suite, Juno Financial Suite, Acquiring

These are three stages of a card payment. Authorisation is approval to charge — the issuer confirms funds are available and reserves them, but no money moves. Capture flags an authorised amount to be collected, signalling that the transaction should proceed to settlement; in hospitality this often happens later than authorisation, for example a deposit authorised at booking and captured at checkout. Settlement is the movement of funds, when the acquirer pays out captured transactions to the merchant. Keeping these distinct matters in hotels because a pre-authorisation, a capture and a settlement are separate events that must reconcile. Juno records each stage so the PMS and the ledger stay aligned.

Related: Reconciliation

Tokenisation substitutes a reusable token for raw card data. Instead of storing or re-using an actual card number for recurring charges, no-show fees or deposits, the system keeps a token that stands in for the card but has no value if exposed. This reduces PCI DSS scope because the obligations apply wherever card data is stored, processed or transmitted — so removing the real card number from terminals, the PMS and staff workflows takes those systems and people out of parts of that obligation. In hospitality, where the same card may be charged at several points across a stay, tokenisation supports deposits, incidentals and balance settlement without holding card details. It underpins how Juno's acceptance layer and Pay-by-Link keep card data out of the PMS.

Related: Pay-by-Link, Juno Hospitality Suite

These terms describe different roles in the payment chain. A gateway routes payment authorisation requests and returns the approve or decline result; it is the routing and decision layer. An acquirer is the merchant's payment processor and settlement provider — it holds the merchant relationship, connects to the card schemes and banking rails, and settles the funds to the merchant. A PSP (payment service provider) is a provider that may offer gateway services, acquiring services, or both, depending on its operating model — so a PSP and an acquirer are not necessarily the same thing. Within Juno, acquiring is provided through Worldline and Getnet, with gateway and orchestration capabilities directing transactions to the appropriate path.

Related: Acquiring

Routing and orchestration direct each transaction to an appropriate payment path rather than sending everything down one fixed connection. Where a property works with more than one acquirer, orchestration can select a path per transaction — for example by market, method or cost — and apply fallback if one path is unavailable, so a payment can still be attempted. For the property this means one integration with the acquirer connections handled behind it. The live site describes this as routing and orchestration across multiple acquirers, with fallback and directing each transaction to the best or lowest-cost path. The accurate record produced at this layer is what later flows into settlement and reconciliation in the Juno Financial Suite.

Related: Juno Financial Suite, Acquiring