The data hotels do not see
The information is unevenly shared: your PSP and acquirer hold transaction data that the hotel merchant never sees directly. They retain a substantial set of signals gathered when the original booking payment was processed. Those signals helped determine the transaction's authorization path. Once a dispute is raised, they become part of the record reviewed by the acquirer and card network, alongside the evidence you provide.
Knowing what sits in this hidden layer helps in two ways. It shows how your acceptance decisions appear to a reviewing institution, rather than only to your team. It also clarifies which merchant-side controls can create signals that affect the outcome, instead of simply increasing the paperwork.
Signals captured during authorization
A payment sent through your booking engine or direct payment terminal moves from your PSP to your acquirer, then to the card's issuing bank. Each stage records transaction metadata. The issuing bank can see the BIN (Bank Identification Number), including the card type, issuing institution, and country of issuance. It can also see whether the payment was card-present or card-not-present, meaning the physical card was used or only its number. If performed, the 3D Secure authentication result is recorded too.
Your acquirer and PSP also retain information the issuing bank may not receive. This can include the IP address used to submit the payment, the device type inferred from browser headers, and often a device fingerprint hash. That hash can link the same device across transactions. The PSP may also track card velocity across its network, including whether the card number appeared recently at other merchants and how often.
These signals are created during authorization. You may not see them as the hotel merchant, but your acquirer can consult them when a dispute is filed against the transaction.
What your acquirer checks in a dispute response
A cardholder dispute causes the issuing bank to raise a chargeback with your acquirer. The acquirer then notifies you and requests evidence. At the same time, it retrieves the original transaction record to assess the dispute before it turns into a financial loss.
Consistency matters to the acquirer. A BIN country of South Africa, a device IP address from South Africa, and a booking made during normal hours for a domestic leisure traveler form a coherent set of signals. That context may be passed to the card network reviewer considering your response. By contrast, a BIN country outside the region, a device IP address resolving to another country, a booking made at 2am, and an email address created within 48 hours of booking indicate higher risk. Your evidence then faces closer scrutiny.
The hotel does not directly receive the PSP's original risk assessment. Still, that assessment affects how credible the dispute appears. A booking rated low-risk at authorization and later disputed as unauthorized is a stronger merchant case than one that showed several risk indicators but was accepted without friction.
3D Secure authentication and liability shift
3DS2, the current version of 3D Secure authentication, matters directly for chargeback liability. If 3DS2 authenticates a transaction and the cardholder later says it was unauthorized, liability can move from the merchant to the issuing bank. The bank carried out the authentication and approved the payment. Known as liability shift, this is one of the most actionable tools available to a hotel merchant seeking to reduce exposure on authorized-but-fraudulent bookings.
Some booking channels and payment flows do not support 3DS2. A direct booking through your own booking engine should be able to invoke 3DS2 when configured correctly. OTA bookings use the OTA's payment rails, so the OTA, not you, decides whether 3DS2 is used. That difference between direct and OTA payment flows has real consequences for chargeback risk allocation.
How TurnStay booking data enters the dispute record
TurnStay records the device fingerprint, IP address, BIN-country match, email account age, card booking velocity, and resulting risk score for each reservation. If a dispute arrives, the evidence export places this booking-time information in a formatted document for inclusion with your submission to the acquirer.
A risk score and its supporting signals cannot guarantee a dispute win. They provide a documented record that your property checked the booking for fraud indicators before accepting it. This due diligence changes the dispute's framing. A merchant with a systematic booking review process presents differently to an acquirer from one with no booking-time data. If TurnStay marked a booking low-risk and it later proved fraudulent, you can show that the available signals were assessed and appeared clean then. That is more defensible than having carried out no evaluation.
This system does not eliminate every chargeback. Fraudsters change tactics, clean BIN signals can be compromised, and some fraudulent bookings resemble legitimate ones when made. The aim is systematic risk reduction and stronger evidence when disputes arise, not a promise of zero disputes.
Ready to optimise your rates and screen your bookings?
Start a 14-day free trial. No credit card required.
