Ferries and Cruise Lines Are Moving Boarding Passes Into the Wallet Because the Dock Is Where the Signal Dies

It's 6:50am at the Woods Hole terminal in Massachusetts. A commuter with a laptop bag and a coffee walks toward the gangway. Behind her, a family of five drags two coolers and a stroller. A deckhand stands at the head of the ramp, and the line behind him is growing.

Nobody here is thinking about their phone signal. They should be.

Terminals sit at the edge of things. The building backs onto water, a breakwater or a hill, and the cell tower is whatever the nearest town could justify. Hundreds of people arrive within the same twenty minutes, and every one of them pulls out a phone at the same moment. Whatever the boarding system asks that phone to do, it asks hundreds of times at once.

That is why ferry and cruise operators are quietly moving the boarding pass out of the app and into the wallet. This piece covers what changes when you do, who has already done it, and what you should copy if you run a boat, a pier or a booking system that feeds one.

The dock is the worst place to need the internet

Airports spend millions on Wi-Fi and distributed antenna systems. A ferry slip usually gets neither. The terminal might be a shed with a ticket window. The cruise pier might be a concrete apron a mile from the nearest cell site, with thousands of guests arriving on the same morning.

Most boarding flows were designed in an office with a fast connection. The passenger opens an app, the app calls a server, the server returns a QR code, and the code is scanned. Each step assumes a signal. Break any one of them and a person stands at the ramp with a spinner on their screen and a queue at their back.

The failure is not rare, and it is not dramatic. It is a 40-second delay, repeated across 300 passengers. A crew trying to hold a departure window feels every second of it.

You can think about the problem as three separate risks:

• The app has to open. A forced update, a cold start or a login screen all add friction before the pass even appears.
• The pass has to load. If the code lives on a server, the phone has to reach it. A weak signal turns a one-second fetch into a timeout.
• The reader has to accept it. If the scanner has to phone home for every ticket, the terminal's uplink becomes the bottleneck for the whole boat.

A wallet pass removes the first two. Once it is added, the pass sits on the device. It opens from the lock screen, with no login and no network call. It is a file, not a page. That is the entire argument, and the rest of this article is about how far operators have taken it.

What a wallet pass changes at the ramp

Start with the passenger's side. A wallet pass is stored on the phone when it is added, whether it is an Apple Wallet pass or a Google Wallet transit pass. Tap the side button, double-click, or open the Wallet app, and the pass is there. The barcode renders from data already on the device. No signal is needed to show it.

Now the crew's side. The deckhand does not need to know which app the passenger used, whether they are logged in, or whether their battery saver is throttling background data. They need one thing, a code or a tap that the reader can check.

There are two ways to check it. You can scan a displayed barcode, which is the cheapest to deploy and works with almost any handheld reader. Or you can tap the phone against a reader over NFC, which is faster and needs no screen at all. Both start from the same place, a pass that was loaded before the passenger left home.

Which one fits depends on your hardware budget and your throughput. A ferry with a six-minute turnaround cares about every second at the ramp. A cruise terminal processing thousands of guests cares more about queues than about any one scan. Neither cares whether the passenger has a bar of signal.

There is a second benefit that gets less attention. A pass in the wallet can also appear on the lock screen when the passenger gets close to the terminal. Apple's pass format supports relevance hints, including a date and a set of locations, so a boarding pass can surface itself near the dock without the passenger hunting for it. For a family with a stroller, that is one fewer thing to do with a free hand.

The ferry that did it in 2019

The best-documented case in North America is a ferry service most people only meet in summer. The Steamship Authority runs boats between Woods Hole and Martha's Vineyard, and between Hyannis and Nantucket. Its own announcements say it has served the islands since 1960 and carried more than 3 million passengers and over 670,000 vehicles in 2018.

In a December 2019 announcement, the Authority introduced eFerry, a contactless ticket system. It launched on the high-speed Nantucket service first. Passengers load a ticket into Apple Wallet or Google Pay, then hold an iPhone, Apple Watch or Android phone near the reader. The Authority described itself as the first domestic ferry operator to use near-field communication technology. It named Apple, Google, Pronto CX for ticket design and management, and SKIDATA for the readers.

The list says a lot. The operator did not build a mobile app and hope people installed it. It put the ticket where the phone already keeps tickets, and it bought readers that talk to the wallet directly.

The rollout reached the traditional ferries in September 2020, along with a web app for buying tickets. The Authority said its partners expected passengers to add a ticket to their wallet in about ten seconds. Multi-ride products, including the five-ride Lifeline Card, the 10-ride Ferry Pass and the 46-ride commuter books, were part of the plan from the first announcement.

The details in the Authority's FAQ are where the design shows. A redeemed ticket greys out in the wallet. If a used ticket has not greyed out, the system still detects the earlier use and denies boarding. Round-trip tickets use the same pass for both legs and stay active until the return trip. Reservation changes update the pass automatically, as long as the phone has internet access.

That last sentence is the whole trade. Updates need a connection. Boarding does not have to.

Cruise lines moved the whole check-in to the phone

Cruise terminals have a different problem. The volume is far higher, the paperwork is heavier, and the queue is the product. A guest who spends two hours in a terminal before the vacation starts has already started to resent it.

Large lines have pushed more of that work to the days before sailing. Princess Cruises, for example, runs a pre-arrival process it calls OceanReady. Guests complete their steps in the app or on the web, and the result includes a boarding pass with a QR code. Guests who finish everything can use a faster lane, and those who have not can still check in at the terminal with staff help. Travel agencies that relay Princess's guidance tell guests to save the boarding pass to their phone's wallet before arriving, so that it is available without internet service at the pier. Check the line's current instructions for your sailing, since requirements vary by port.

The advice matters because it comes from the cruise side and not from the wallet vendors. Even a line with its own app tells guests to put the pass somewhere that works without a signal. The operator knows what the pier looks like.

This is the pattern across travel. The booking happens in the cloud, but the moment of truth happens at a gate with a bad connection. The pass is the part you hand to the passenger so the gate does not depend on the cloud.

The queue is the metric

It is easy to talk about this as a technology story. For an operator it is a throughput story, and you should measure it that way.

Consider a representative regional ferry operator, based on an anonymized example. A vessel carries a few hundred foot passengers and a deck of vehicles. The crew has roughly twenty minutes to load. If each passenger takes an extra ten seconds because a code failed to load, 300 passengers cost the schedule about 50 minutes of cumulative waiting, spread across the line. The boat does not leave 50 minutes late, but the crew compensates by rushing the vehicle deck, and that is where mistakes happen.

You should not trust those numbers as a forecast. Every terminal differs. But the shape is right, and it is the shape you should test. Time how long a passenger takes from reaching the ramp to being waved through. Do it with the app, with a printed sheet, and with a wallet pass. Do it again when the terminal is crowded.

The things worth counting are plain:

• Seconds per passenger at the head of the line. This is the number the crew feels.
• Failed first scans. A scan that has to be retried costs far more than one that works.
• Manual overrides. Every time a crew member waves someone through on trust, you have lost your record of who is aboard.
• Support contacts on departure day. "I can't find my ticket" is a message every ferry company knows well.

If wallet passes move any of those, you will see it within a single busy weekend.

Why paper and apps both lose

Paper has the right instinct and the wrong medium. A printed ticket works with no signal and no battery. It also gets wet, torn and left on the kitchen table. It cannot change when the departure moves. A passenger holding a stale printout learns about a delay when they reach the ramp.

An app has the opposite problem. It can change in real time, but it depends on a signal to do so, and it asks the passenger to install, log in and keep it updated. Occasional travellers are the largest group on most ferries. They ride twice a summer. They will not install your app for a short crossing, and the ones who do will forget the password by the time they need it.

A wallet pass sits between the two. It keeps working without a signal, like paper. It updates when a signal is available, like an app. And it needs no install, because the wallet is already on the phone. A pass can be added from a link in a confirmation email or from a button on the booking page, which is how the Steamship Authority does it.

There is one more advantage that matters for weather. Ferries get cancelled. Cruise itineraries change. A pass that can be updated, even if only when the phone next finds a connection, gives you a channel for the message that matters most on the worst day. A printed ticket gives you nothing.

What to copy

You do not need a national NFC programme to get most of this. If you run a ferry, a cruise terminal or a booking platform that feeds one, these are the decisions that matter.

Issue the pass at booking, not at check-in. The pass should reach the passenger's phone (the Apple Wallet pass reference covers the fields) while they still have a good connection, at home or at work. The Steamship Authority puts an "Add to Apple Wallet" button in the confirmation email and on the confirmation page. Do the same.

Put everything the ramp needs on the pass itself. Sailing time, vessel, direction, passenger count and a code the reader can verify. If the crew has to look something up, you have rebuilt the dependency you were trying to remove.

Decide how the reader handles being offline. This is the question most teams skip. A reader that validates against a server fails when the uplink does. A reader that holds the day's manifest locally can keep scanning and sync later. The tradeoff is double-use. Without a live check, a screenshot could be shown twice. Decide how much that risk costs you against the cost of a stalled queue.

Plan the update path. Delays, gate changes and cancellations should push to the pass. Remember that updates need a connection, so tell passengers where to look and treat the pass as the record, not the email.

Keep a fallback. Some passengers will arrive with a dead phone or no smartphone. The Authority still lets them print a reservation or buy a paper ticket at the terminal. A wallet programme does not have to be an all-or-nothing switch.

Test at the dock, not in the office. Stand at the terminal on a busy day with a phone on airplane mode. Open the pass and watch what happens. That test takes five minutes and tells you more than any architecture diagram.

The boat leaves on time

Every transit operator learns the same lesson eventually. The passenger's phone is the one piece of infrastructure you do not pay for, and it is the one piece you cannot control. The best design assumes it will be slow, the signal will be weak and the passenger will be holding a child.

A pass that lives in the wallet respects those conditions. It opens in a second. It works at the end of a pier. It updates when it can and stays readable when it cannot. For a ferry or a cruise line, that is the difference between a calm ramp and a crowded one.

If you run boarding for a ferry, a cruise terminal or a tour operator and want to see what a wallet pass looks like for your sailings, you can try Passmint at https://passmint.com and issue a first test pass before you commit to anything.