The Payment Field That Quietly Kills Your Digital Check-In

A hotel asked us to remove one field from its payment form. The reason was plain: guests do not understand what this is.

The field was a national ID number, sitting on the card entry screen inside digital check-in. Domestic guests recognised it. International guests saw a mandatory box asking for something that looked like a social security number and stopped.

It is worth sitting with how expensive that is. The guest has already booked. They have already opened the check-in link, already read the terms, already decided to proceed. They abandon at the last step, over a field that adds nothing to the transaction. Then they arrive at the desk needing manual check-in - the exact work the digital flow existed to remove.

Why this field exists at all

Payment forms accumulate fields the way old code accumulates comments. Some are required by the card scheme. Some were required by a regulation that has since changed. Some are there because a merchant asked for them once, and the default was never revisited.

The ID field is typically the third kind. It is collected because it can be, and because domestic customers are used to it. Nobody re-examines it when the property starts taking international bookings.

The general rule worth adopting: every field on a payment form should be defensible. If you cannot say what a field is for and what breaks without it, it is costing you money.

The part that catches people out

Removing a field seems trivial. It is a parameter change. And in this case the provider confirmed the parameter quickly enough: set the field to hidden or optional when initialising the payment session.

But the documentation had a gap, and the gap mattered. The parameter table listed several possible values for that field - optional, mandatory, a pre-filled value, an input value - and simply did not document a hide option, even though other fields on the same form explicitly did. So the obvious question was whether hiding was actually supported for that field or whether optional was the correct route.

That is a normal situation with payment integrations. Documentation is written per feature by different people at different times, and consistency between fields is not guaranteed. When a value is missing from one field's documented options but present for others, ask rather than assume. Trying it and observing that the form renders is not confirmation; it tells you nothing about how the transaction is processed downstream.

The genuinely surprising answer

The second question was the important one: does changing this field affect 3D Secure?

The answer came back that the ID field has no effect on 3DS at all. But the provider volunteered something far more valuable, unprompted:

The decisive field for 3DS on this payment page is the cardholder name. If it is not set as mandatory, the transaction never goes out for 3DS verification, and does not process as an internet transaction.

Read that again, because it is the kind of thing that silently costs a hotel money for months. A merchant tidying up their payment form, making fields optional to reduce friction, could switch off 3D Secure without any visible symptom. The form still works. Cards still get charged. The transactions are simply categorised differently, which changes liability for chargebacks and can change your rates.

There is no error message for this. Nothing on the page looks wrong.

What this means practically

Ask which fields are load-bearing before you change any of them. Not can I hide this, but what depends on this. The person answering support tickets at your payment provider often knows things that are not in the manual, and they will usually tell you if you ask a specific question.

Change one field at a time. If you remove three fields and approval rates drop, you have three suspects and no easy way to isolate them.

Test the transaction, not the form. Run a real low-value payment end to end and confirm it reached the state you expect: authorised, 3DS-verified, correctly categorised. A form that renders perfectly while quietly downgrading every transaction is the worst possible outcome, because nothing surfaces until a chargeback arrives.

Confirm where the change lives. Some settings are yours, set when you initialise the session. Others are configured on the provider's side against your terminal. Getting this wrong means shipping a change that appears to do nothing.

The wider point about check-in friction

Digital check-in only pays for itself if guests finish it. Every field is a place to stop, and the cost of a field is not evenly distributed - it falls hardest on exactly the guests who are least like your domestic default.

Go through your check-in flow as an international guest with no context. Every question you cannot answer confidently is a question that is costing you completions. Most of them will turn out to be defaults nobody chose.