PCI DSS compliance for mobile apps: cruise payment providers in 2026

TL;DR

PCI DSS compliance for mobile apps on a cruise ship in 2026 comes down to where the card number lives: in the guest app, on a crew phone, on a ship server or only with a PCI-validated provider. We ranked six payment providers on five criteria they document in public. Adyen ranks first as the only one documenting all five, from an Oracle cruise partner listing to a Tap to Pay on Android SDK with PCI MPoC certification.

• The PCI Council closed SPoC and CPoC to new submissions on October 31, 2026. New phone-based acceptance goes to MPoC.
• PayPal Braintree has the strongest shipboard reference: Norwegian Cruise Line Holdings runs reservations and all shipboard card payments through it.
• Stripe denies a Tap to Pay payment in a new country, so for a ship it is a home-port tool.

On a cruise ship the card enters once and the folio keeps it

Onboard, the card rarely appears at the point of sale. Royal Caribbean's SeaPass FAQ describes a cashless onboard account set up with a credit card or as a cash account. A card account starts with a $100 pending authorization, and spending above that adds more holds.

So PCI scope sits where the card is registered, where the onboard account keeps it, and where the ship settles with the processor. Oracle's implementation guide for its Shipboard Property Management System (SPMS) 23.2, dated October 2024, lists the tables and files that store cardholder data, including the full card number encrypted with AES-256 data keys. Online authorizations return a token or reference that SPMS reuses for incremental authorizations and settlement. Oracle validated SPMS under the PCI Software Security Framework and states that PCI compliance itself is the merchant's job.

Four places card data enters a cruise app

PCI DSS covers anyone who stores, processes or transmits card data. In a cruise line's apps, that happens in four places.

1. Pre-cruise purchases in the guest app, paid by card outside Apple and Google billing, as our onboard revenue guide explains.
2. Card registration for the onboard account at online check-in. This card backs every charge of the voyage.
3. Crew taking cards on phones and tablets at a spa desk, an excursion counter or a pop-up bar.
4. Ship servers, which can hold card data for store-and-forward, incremental authorizations and settlement until the shore link returns. Links drop: Starlink's global outage on July 24, 2025 lasted about two and a half hours, per ISPreview. The PCI Council's FAQ 1154 sets no time limit on card data held before authorization, requires it to be protected, and lets each card brand decide whether it may be stored at all.

The guest's phone is the easy part. FAQ 1283 puts the cardholder's own device outside the merchant's assessment. The app's development stays in scope under Requirement 6, and so does any backend that receives the card on the guest's behalf.

Apps still slip. Cardpliance, a study of 358 popular Google Play apps that ask for a card number, found 1.67% failing its PCI DSS checks, with card numbers and verification codes stored improperly. The fix is a token from the provider's SDK or hosted field. Stripe's security guide says card type, last four digits and expiry are not subject to PCI compliance, while untokenized card numbers can mean more than 300 PCI DSS controls. Our HIPAA compliant payment processing guide draws the same boundary in a health app.

SPoC and CPoC closed to new submissions on October 31, 2026

Crew payments on phones got a deadline this year. On May 1, 2026, the PCI Security Standards Council opened a sunset period for its Software-based PIN Entry on COTS (SPoC) and Contactless Payments on COTS (CPoC) standards. It ended on October 31, 2026, and the Council now accepts no new submissions under either. Listed solutions stay valid until their normal expiry dates.

The replacement is MPoC, Mobile Payments on COTS. Version 1.1, published November 26, 2024, allows PIN entry and contactless reading on the same phone. On May 20, 2026, the Council added an MPoC SDK Integration Report v1.1 for products that embed a listed MPoC SDK. A crew payment app you commission now belongs on an MPoC SDK, or on Tap to Pay on iPhone through a provider that supports it in every country on your itinerary.

PCI DSS v4.0.1 was published in June 2024 with no new or deleted requirements, and its future-dated requirements took effect on March 31, 2025. SAQ A then dropped requirements 6.4.3 and 11.6.1 for a criterion: the merchant confirms its site is not susceptible to script attacks. FAQ 1588 applies it when a provider's payment form is embedded in your page, as in an iframe; a redirect to the provider is exempt. A WebView that opens your web checkout runs that page and its scripts, so hold it to the same rule.

How we evaluated

Five criteria, credited only when the provider's pages or trade press document them:

1. Cruise evidence: a cruise line or a cruise system vendor naming the company.
2. PCI validation: PCI DSS compliance or certification, as the provider states it.
3. Mobile scope reducers: SDKs, hosted fields or Tap to Pay that keep the card number out of your code.
4. Ship fit: card acceptance while the shore link is down.
5. Offline risk: who pays when an offline payment fails, in writing.

The order follows the number of criteria met; ties go to the stronger cruise reference. We started from the three pages that rank for this query: Capgo's requirements post, Clover's developer guidance and Enigma Vault's tokenization ranking. None covers payments at sea.

Verifone and Transaction Services, also on Oracle's cruise list, publish no cruise detail beyond it. Software developers build on these providers rather than replace them, so Mercury Development, which wrote this guide, is not ranked. Facts come from company documentation and trade press opened on November 6, 2026. Any group in our own data with fewer than three data points is not published.

The six providers at a glance

1. Adyen

Adyen ranks first because it is the only provider here that documents all five criteria. It is on Oracle's list of cruise partner integrations. Its PCI DSS guide says Adyen is a PCI DSS Level 1 Service Provider assessed every year by an independent QSA. In November 2025, Adyen announced that its Tap to Pay on Android SDK is PCI MPoC certified, on Android 12 or higher. Its offline payments page is candid: store-and-forward payments are approved without verification, the Mobile SDK can run them for 24 consecutive hours, and the merchant is fully liable for failed captures, chargebacks and disputes.

Best for: crew phones and terminals on one acquirer, with offline limits set per device. Facts: PCI DSS Level 1 Service Provider. Watch-out: we found no cruise line naming Adyen as its processor, only the Oracle listing, and the MPoC announcement covers Android.

2. PayPal Braintree

Braintree has the clearest shipboard reference in this list. PayPal's February 2025 release says NCLH will continue to use PayPal Braintree for card processing on reservations and all shipboard payments, and that US-based reservations for Norwegian Cruise Line, Oceania Cruises and Regent Seven Seas Cruises now accept PayPal checkout. NCLH counted 32 ships at the time. Braintree's checkout UI comparison says Drop-in UI, Hosted Fields and its mobile SDKs typically qualify a merchant for SAQ A, and PayPal's compliance page says PayPal is fully PCI compliant.

Best for: one processor from booking to the onboard account, with native SDKs in the guest app. Facts: part of PayPal. Watch-out: none of the pages we read describes offline acceptance at sea or who carries offline risk, and the PayPal wallet covers US-based reservations only.

3. PXP

PXP is built around the shipboard PMS. In June 2023, its AnyPay platform achieved Oracle Validated Integration with Oracle Hospitality SPMS. It uses point-to-point encryption and tokenization and can store payments, chip and PIN included, until the connection returns. Oracle's SPMS guide lists Servebase/PXP among its supported online processors. In December 2019, PXP announced a PCI DSS Level 1 Service Provider certification for ANYPay, its 12th consecutive accreditation. Its embarkation note says offline mode returns a pseudo-auth, and that many operators still swipe cards and authorize days later, sometimes after the cruise has ended.

Best for: card registration at embarkation and folio authorizations in an Oracle SPMS fleet. Facts: Oracle Validated Integration since 2023. Watch-out: we found no SDK for a guest app, its cruise page names no cruise line client in its text, and incremental authorizations wait until the store-and-forward file is processed. The Level 1 announcement dates from 2019, so ask for the current attestation of compliance.

4. Stripe

Stripe brings the closest public analog to cruise crew: an airline cabin. In November 2023, Alaska Airlines and Stripe began rolling out Tap to Pay on iPhone so more than 7,000 crew members could take payments on airline-issued iPhones without a separate terminal. Stripe is certified every year as a PCI Level 1 Service Provider, and its docs carry an offline payments guide for Tap to Pay on iPhone. In Store and Forward mode, per Apple's Tap to Pay security page, encrypted card data stays on the phone only until it is sent. The catch for a ship is geography. Stripe's Tap to Pay FAQ says Tap to Pay will not work if brought across borders and denies a transaction when a new country is detected, and its regional guide requires the Stripe account and the reader's location to be in the same country, in local currency.

Best for: crew iPhones that stay in one country, such as a home-port cruise terminal. Facts: PCI Level 1 Service Provider. Watch-out: as documented, Tap to Pay on Stripe does not travel with a ship that calls at foreign ports, so get written confirmation before you plan crew payments at sea on it.

5. Worldpay

Worldpay holds a named cruise reference on the acquiring side. In October 2021, Cruise & Ferry reported that NCLH chose Worldpay for global acquiring and processing across its three brands, with 3DS Flex for PSD2 Strong Customer Authentication. Worldpay for Platforms, a Worldpay unit, says on its compliance page that its infrastructure is certified at PCI DSS Level 1. On January 12, 2026, Global Payments completed its purchase of Worldpay; the combined company reports more than 6 million merchant locations and about 94 billion transactions a year.

Best for: a line selling in Europe that wants acquiring and 3-D Secure from one large provider. Facts: part of Global Payments since January 2026. Watch-out: the pages we read describe no mobile SDK or offline acceptance at sea, and NCLH's 2025 release names Braintree for card processing, so ask which layer Worldpay still holds there.

6. Paysafe

Paysafe covers the booking stage. In November 2022, Seatrade Cruise News reported that Virgin Voyages picked Paysafe to process online card payments and accept currencies besides the US dollar. Paysafe also manages the risk of fares paid months before sailing, with a product that shows the holdback and release of funds, and handles fraud and chargebacks with in-house teams. Its developer PCI page says merchants using its iOS and Android SDKs with single-use tokens are expected to fall under SAQ A, while passing the full card number means SAQ D.

Best for: card-not-present booking payments in several currencies. Facts: more than 20 years of card-not-present experience, per the report. Watch-out: the report covers online booking only, and the developer page does not state Paysafe's own PCI DSS level.

Which provider fits your payment flow

What a provider leaves to your app team

A provider takes the card. The session, the folio and the ship stay with your team, and two reviews show where that line falls.

First, our published case studies, reviewed on November 6, 2026. Around 10% of the case studies in Mercury Development's portfolio take payments from users, and each used a different channel: a payment gateway built for client-side PCI compliance on Grant's, a wallet for payments and payouts on GreenLinks, and App Store, Google Play and Shopify subscriptions on Hit It Great.

Second, our cruise programs. For cruise line clients Mercury cannot name under NDA, PCI DSS and ADA were release conditions, and some failures keep coming back. A login token issued on shore stops working on the ship's network, so payment screens need their own session check. An API works in production and not in the test environment. And a guest's payment methods can sit in two records, one ashore and one on the ship, so the app has to know which one it charges.

None of that ships in a provider's SDK. It is the layer Mercury Development builds. For OneSpaWorld, which describes itself as the operator of health and wellness centers onboard cruise ships, we built an onboard spa platform as ReactJS web apps on ship servers with no external internet. Its checkout prices dynamically with offers from OneSpaWorld and the cruise lines, reaches each line's API through middleware. The platform has run since 2018 on over 160 ships operated by multiple cruise lines. Mercury Development has built software since 1999 with 500+ engineers, delivers PCI DSS compliant payment flows on providers like the six above, and works under work-for-hire, so the customer owns the code and all underlying IP.

Keep the card number off the ship

Opinion, with the mechanism.

Most cruise PCI programs start with the processor contract. Start instead with a map of every place a card number can exist: the guest app, the crew device, the ship server, the folio, the logs. Then remove each one you can. The provider's SDK keeps the number out of your app's code and servers, though the app's development still answers to Requirement 6. An MPoC SDK or Tap to Pay takes the crew phone off. A token in the folio takes most of the ship database off. What stays is store-and-forward, and it belongs on certified devices with a floor limit, away from servers you patch at sea. Our offline-first ship apps guide covers the rest.

Then change the vendor interview. Skip "are you PCI compliant". Ask: "The satellite link drops at 9 p.m. on a sea day and a guest pays for a massage. Show me where the card number sits until the link returns, who can read it, and who pays if the authorization fails." A team that has built this answers with a device, a key and a floor limit. A team that has not answers with a certificate.

Written by Alexey Rodionov, Lead Front-end Developer at Mercury Development since 2020. Alexey is a Google Developer Expert in Web Technologies and a Chromium contributor whose code ships in Chrome DevTools, Google's Bubblewrap and Microsoft PWABuilder. The review of payment integrations in Mercury Development's cruise programs and published case studies belongs to the architecture and integration decisions his practice is responsible for.

Mapping card data across your apps and ships? Start with the flows

Send us the payment flows you run today: what guests pay for in the app, where crew take cards, which system holds the onboard account and what happens when the ship loses its link. We will mark where card data can exist in each flow and which change to make first.