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.
Your PMS picks the provider and merchant account for each property’s payment, and Orchestra sends it there. Every property uses the same API.
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.
Each property keeps its own provider and merchant account, stored with Orchestra under an account name. Your PMS sends the same request for every property; only the account name changes.
One stored card covers the stay: the deposit at booking, the balance on schedule, a hold at check-in and a partial capture of that hold at check-out. The hold sits with the provider on the guest’s card.
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, which returns a token. Your PMS keeps the token for later charges and never receives card data.
Your PMS sets a primary provider and an ordered fallback list. When the deposit fails at the primary, Orchestra tries the next provider, and the booking is confirmed on the first approval.
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
- Configure a property
- Create a payment token
- Schedule the balance
- 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.
Free · Up to 100 live requests per month · Unlimited sandbox testing · No credit card required