Guest Cards from OTA Bookings

On the payment page for that booking, in the Guarantee section. It appears when the booking arrived with card details attached.

Without revealing anything you can already see what you usually need:

• The card brand
• The last four digits, shown as •••• 1234
• Valid Thru — the expiry
• CVV / CVC — whether a security code is Present or Absent
• Is Virtual — whether it is a real card or a virtual one issued by the OTA

That is often enough. If you only need to know whether a chargeable card exists, you never have to reveal it.

To see the full number, use Reveal Card.

Four steps, with a code sent to your email in the middle.

1. Press Reveal Card. Amiqa explains what happens next: "For security, a 6-digit verification code will be sent to your registered email address. The code expires in 5 minutes." Press Send Code.
2. Check your email for the six-digit code. The message includes the guest's name and booking reference so you know which request it belongs to.
3. Enter the code. A countdown shows how long you have — Expires in — and if it does not arrive there is Resend.
4. Press Verify. The card appears in a secure window, marked Verified.

The card is displayed inside a secure frame provided by the vault, not by Amiqa — which is why the number itself never passes through your PMS.

Card numbers are never stored by Amiqa. They live in a dedicated payment vault, and the message on screen says it plainly: "Card data is never stored on our servers."

What that means in practice:

• Amiqa holds only a token — a reference with no card number in it
• The card renders inside the vault's own secure frame, not in Amiqa's page
• Every successful view is logged — who looked, when, from where, and on which device

This is what keeps you PCI compliant: card numbers never touch Amiqa's servers, so your PMS is never handling raw card data.

That log is a feature, not surveillance. If a guest ever disputes a charge, you can show exactly who accessed the card and when. And because everyone on your team knows views are recorded, cards get looked at when there is a reason to.

Reveal a card when you need to charge it, not out of curiosity.

Amiqa asks you to confirm: "Your session will end. You'll need to verify again to reveal card details." Press End Session and the view closes.

It is a deliberate speed bump. Closing genuinely ends access, so a card cannot sit revealed on a screen at a busy front desk where anyone walking past can read it.

If you still need the number, finish what you were doing before closing.

Yes, with Delete Card once you have verified. It confirms first: "Are you sure you want to permanently delete this card? This action cannot be undone."

Reasonable reasons to delete one:

• The guest paid by another method and asked you to remove it
• The stay is finished and settled, and you would rather not hold it
• The guest asked you to, which in many places they are entitled to do

It cannot be undone. If the booking is still ahead of you and your policy might require a charge, keep it until after checkout.

Cards are removed automatically seven days after the guest checks out. You do not have to do anything.

That window is deliberate. It leaves you time to settle a folio, apply a no-show charge or handle a damage claim, then removes the card so you are not holding payment details for guests who left months ago.

So a card that has disappeared from an old booking has not been lost — it aged out as designed.

Each one tells you what to do next.

Sync Card is the one worth remembering. Occasionally a booking arrives before its card does. Sync fetches it directly from the channel, and usually resolves it.

The attempt counter tells you how many tries remain, so you know whether to keep going or request a fresh code.

Viewing needs booking read permission, and deleting or syncing needs booking update permission. If you cannot see the Reveal Card option at all, you do not have the permission for it.

Worth thinking about deliberately. Front desk staff usually need to see cards to settle folios. Housekeeping and maintenance do not. Since every view is logged, keeping access to the people who genuinely need it makes the log meaningful — and makes any dispute straightforward to investigate.

When your cancellation policy says so, and the guest agreed to that policy when they booked. Commonly:

• A late cancellation inside your no-refund window
• A no-show, at whatever your policy sets — usually the first night
• The balance on arrival, where the guest is paying by that card anyway
• Damage or extra charges, where your terms cover it

Two things protect you here. Your cancellation policy is what the guest accepted, and it is stored on their booking exactly as it was when they booked. Your terms and conditions cover damage and house rules.

If your policy does not cover what you are about to charge, talk to the guest first. A charge they did not expect becomes a chargeback and a public review, and both cost more than the amount involved.