OTA, Payment and Lock Integration — What to Scope

Which integrations matter most?

OTA channels, payments, door locks, identity and accounting are the common core. A property with an outlet needs POS; a property with a PBX needs telephony. The list should follow the operation, not the partner page.

How does OTA sync work?

The channel manager pushes availability, rates and restrictions and brings reservations back. Room, rate and tax mapping is the fragile part; mapping errors usually surface at the desk.

How do payments connect?

Terminals and gateways post to the folio with a traceable reference. Settlement reconciles to the ledger. The PMS should not store full card data; the provider tokenises or processes it.

How do door locks connect?

The PMS sends the room and stay to the lock system; the desk issues a key. Mobile credentials require an access layer. Compatibility depends on the lock model and the vendor API.

Who owns a failure?

Each interface should have a named owner and an escalation path. The PMS vendor owns the interface it delivers; the third-party vendor owns its side. The property needs a fallback procedure.

What should be tested?

One end-to-end transaction per critical interface, plus a failure case. Test a key issue, a payment reversal, a channel reservation and an accounting export before signing.

How do you write an interface scope?

Name the system, the model, the interface version and the direction of data. “Door lock integration” is not a scope; “this lock model, this encoder, key issue and room move, vendor API version” is.

State what is native, what is partner-certified and what is custom. State who pays for the interface and who owns the vendor relationship.

Add the failure path: what the desk does when the interface is down, who is called and how the transaction is reconciled.

What should the interface test plan cover?

One happy path and one failure path per critical interface: a key issue and a revoked key, a payment and a reversal, a channel reservation and a cancellation, an accounting export and a correction.

Test with the property's own data, not a demo room. Use a real rate code, a real tax treatment and a real guest profile.

Record the result and the owner. A test that passes without a written result is an opinion.

What if a vendor has no API?

Options are a file exchange, a middleware adapter, a manual procedure or replacing the system. Each has a cost and a failure mode. A manual procedure is acceptable only if the volume is low and the reconciliation is owned.

Do not let a vendor promise an interface it has not built. Ask for the API documentation, the sandbox and a reference installation.

If the interface cannot be supported, say so before the project is priced. A late discovery is more expensive than an honest scope.

How do you monitor interfaces after go-live?

Each interface should log calls, retries and failures, with an alert when the failure rate crosses a threshold. The property needs a daily view, not a monthly report.

Name the owner for each interface and the escalation path. A failure at 23:00 should not depend on someone reading email in the morning.

Review the interface log after an upgrade and after a channel change. Most failures are configuration drift, not code.

How do you phase interfaces?

Phase by guest impact: payments and door locks first, then channels, then accounting and BI. A failed payment or lock stops an arrival; a late report does not.

Do not enable a new channel before the rate and room mapping is tested. A channel that sells the wrong room type creates a guest problem at the desk.

What is a reasonable integration budget?

It depends on the vendor and the interface. A standard, documented interface is a small line; a bespoke connection can be a project. Ask for the estimate and the assumptions.

Include the third-party fees and the internal testing time. The integration budget is not just the vendor invoice.

How do you document an integration?

Keep a one-page sheet per interface: systems, models, versions, data direction, owner, test result and fallback. Store it with the contract.

Update it after every upgrade or vendor change. Most integration failures are configuration drift, and the sheet is how you spot it.

What does a 90-room city hotel integration plan look like?

The reference scenario is a 90-room city hotel with a restaurant, a bar, a channel manager, card terminals and an older lock system. The critical path is payments and locks; the channel and accounting follow.

Phase one: payment terminal and gateway, tested with a sale, a reversal and a settlement reference. Phase two: door lock and key issue, tested with a new key, a room move and a revoked key. Both must pass before the first arrival on the new system.

Phase three: channel manager, with room and rate mapping tested on a closed date, a stop-sell and a cancellation. Phase four: accounting export, reconciled by the controller. Phase five: the POS charge-to-room and the telephony interface, if applicable.

Each phase has a named owner, a test result and a fallback. The hotel keeps a one-page sheet per interface, with the model, version and escalation path.

After go-live, the interface log is reviewed daily for the first week and weekly after that. Most failures are mapping or configuration drift, not code.

What does a failed integration look like?

It starts with a logo on a partner page and no named model. The property assumes the lock, terminal or channel is supported; the vendor assumes it is someone else’s interface.

The second failure is a happy-path test only. The key works, but the revoked key does not; the payment works, but the reversal does not; the channel reservation arrives, but the cancellation does not.

The third is unclear ownership. When the interface fails at 23:00, the PMS vendor points to the lock vendor, the lock vendor points to the network, and the desk is left with a guest.

The fourth is no monitoring. The interface fails silently for a week, and the property discovers it in the reconciliation.

A good integration is specific: model, version, owner, test, fallback and log. The specificity is the difference between a connection and a promise.

What is the final integration checklist?

Confirm the exact model, interface version, owner and test result for every critical interface. Confirm the fallback procedure and the escalation path.

Then test one failure case per interface. A key that cannot be revoked, a payment that cannot be reversed or a cancellation that does not reach the PMS is a go-live risk.

• Model and version
• Named owner
• Happy-path test
• Failure test
• Fallback procedure
• Escalation path