. Read more →

All events

Sign up/Login
Contact sales

Hospitality & property management

Every property processes payments differently. Your code shouldn’t.

Select the provider, merchant account and supported payment method for each property and transaction.

Get your sandbox account
View documentation
Your PMS sends a $280 payment for Apartment Group through Orchestra to Provider C, with the same API for every property; each property keeps its own payment setup
Your PMS sends a $280 payment for Apartment Group through Orchestra to Provider C, with the same API for every property; each property keeps its own payment setup

Property-level control

One API. Separate payment settings for every property.

Keep provider credentials, merchant accounts and payment rules isolated by property while your PMS uses the same request contract.

Beach Resort settings: Provider B, merchant account account_08, capture at checkout, on the same PMS integration
Beach Resort settings: Provider B, merchant account account_08, capture at checkout, on the same PMS integration
Stay folio 5812: $150 deposit paid, $420 balance scheduled, $200 check-in authorization held, $48 check-out adjustment added
Stay folio 5812: $150 deposit paid, $420 balance scheduled, $200 check-in authorization held, $48 check-out adjustment added

The full stay payment flow

One guest stay. Every payment moment.

Handle deposits, scheduled balances, check-in authorization and check-out adjustments through one connected payment flow.

Availability depends on the selected provider and payment method.

Card data boundary

Collect card details once. Keep them out of your PMS.

The embedded form sends card data directly to Orchestra. Your application receives a reusable token for deposits, balances and supported later charges, while raw card data does not reach your servers.

Card details go from the embedded form to Orchestra; your PMS receives only a token for the deposit, balance and incidentals
Card details go from the embedded form to Orchestra; your PMS receives only a token for the deposit, balance and incidentals
Beach Resort: primary provider failed, fallback A approved, fallback B not attempted
Beach Resort: primary provider failed, fallback A approved, fallback B not attempted

Ordered payment continuity

Keep the booking moving when a payment fails.

Define the primary provider and an ordered fallback list. Orchestra retries each provider in the configured order until the payment succeeds or the list is exhausted.

PMS developer FAQ

Questions you probably have.

Property scope: one PMS, multiple payment configurations

Can each property use a different provider and merchant account?

Yes. Select the property configuration for each transaction while your PMS keeps the same integration.

Can the PMS store only reusable payment tokens?

Yes. The embedded form sends card data directly to Orchestra. Your PMS receives a reusable token for deposits, balances and supported later charges, and raw card data does not reach your servers.

Can we schedule balances before arrival?

Yes. Schedule the balance as a future charge on the stored token. Availability depends on the selected provider and payment method.

What happens when the primary provider fails?

Orchestra retries each provider in your ordered fallback list until the payment succeeds or the list is exhausted.

Test scenario

  1. Configure a property
  2. Create a payment token
  3. Schedule the balance
  4. Test provider fallback

Sandbox for the full stay flow

Test property-level payments before the first guest arrives.

Use the sandbox to validate property configuration, token reuse, scheduled charges and supported recovery paths.

Get your sandbox account
View documentation

Free forever · Up to 100 live requests per month · Unlimited sandbox testing · No credit card required