Ship a wallet pass with no developer account and no certificates

The short version

A wallet pass isn't a design file. It's a cryptographically signed bundle, and Apple will only install one whose signature traces back to a Pass Type ID certificate issued to a paid Apple Developer account. That single requirement is why "add a loyalty card to Apple Wallet" sounds like a software project rather than a Tuesday afternoon.

On a platform like Waya, that certificate is ours, not yours. You upload a logo, pick colors, set the stamp count, and the signing happens on our servers every time a customer enrolls. There's no Apple account to open, no .p12 file to guard, no OpenSSL command to get wrong, and no app review.

Two things Waya doesn't do, before you read further: it doesn't integrate with your till, and it doesn't send SMS. The free tier also stops at 100 customers and 100 wallet messages a month. What it does replace is the entire certificate-and-signing layer described below.

What Apple actually requires to sign one .pkpass

It starts with the account. Pass signing needs an Apple Developer Program membership, listed at 99 USD a year on developer.apple.com as of 18 August 2026 — roughly 371 SAR at the riyal's pegged rate of 3.75 to the dollar. Check the current price yourself before you budget it. Inside that account you register a Pass Type ID, an identifier that must begin with pass., such as pass.com.yourshop.loyalty.

Then the certificate work. You generate a certificate signing request, upload it, download the resulting Pass Type ID certificate, and bundle it with its private key into a .p12. You also download Apple's Worldwide Developer Relations intermediate certificate — the G4 generation, because older ones fail the chain check — and note your 10-character Team ID.

Now the file. A .pkpass is a zip archive containing pass.json, whose passTypeIdentifier must exactly match your certificate and whose teamIdentifier must match your team. Alongside it sit your images, where icon.png and [email protected] are mandatory, a manifest.json holding a SHA-1 hash of every other file, and a detached PKCS#7 signature computed over that manifest. Serve the result with Content-Type: application/vnd.apple.pkpass, or Safari hands the customer a zip file instead of an Add button.

Get any byte of that wrong and iOS gives you one message: "Sorry, your Pass cannot be installed." No field name, no line number. In practice it's nearly always a manifest hash that no longer matches a file you regenerated, or a signature computed over the wrong bytes.

Google Wallet asks for different homework

Google doesn't use .p12 signing at all, so none of the work above carries over. You apply for a Google Wallet API issuer account in the Google Pay and Wallet Console. That's an approval process, not a signup form, and it ends with a numeric issuer ID.

Next you create a Google Cloud service account, download its RSA private key, and grant it access to that issuer. Cards then exist in two layers: a loyalty class, which is the template holding the shop name, logo, and program rules, and a loyalty object per customer holding their points and barcode. Both live inside Google's API under IDs prefixed with your issuer ID.

The "Add to Google Wallet" button isn't a link to a file either. It's a JWT signed with that service-account key, referencing the class by ID. The class has to exist and be current before any object can point at it, so every design change means an API update before the next save link is generated.

The part nobody warns you about: keeping passes current

A loyalty pass that shows Thursday's stamp count on Saturday is worse than no pass. Making a pass live is a second project, and it's bigger than the first one.

On the Apple side, each pass you sign carries a webServiceURL and its own authentication token. You then have to run the REST service Apple calls against it: the device registers with a push token, later asks which of its passes changed since a given timestamp, and downloads fresh copies. You trigger those checks by pushing through APNs with your pass certificate. If that service is down, passes quietly freeze and nobody tells you.

Google's side is one PATCH request per loyalty object, which sounds easier right up to the point where you're pushing a few thousand updates and dealing with rate limits, partial failures, and retries.

Then there's the calendar item. Pass Type ID certificates expire. When one lapses, new passes stop installing and existing passes stop updating, and no dashboard anywhere explains why. On Waya, tracking and rotating that certificate is our operational problem, not a reminder in your phone.

What the platform route swaps in

On Waya the sequence looks nothing like the above. Create an account, name the card, pick your colors, upload your logo, choose how many stamps buy the reward, and write the reward line in Arabic or English. Save it, and you get a QR code to print for the counter.

A customer scans that code and sees one screen asking for a first name and a mobile number. One tap adds the real pass: Apple Wallet on iPhone, Google Wallet on Android, and a web card on anything else. It's about ten seconds, with no app install, no password, and no account to create.

Everything from the previous four sections stays on our side: the certificate, the manifest hashes, the PKCS#7 signature, the PassKit web service, the APNs pushes, the Google class sync, and the retry logic. By our own published figures, 100+ shops across Saudi Arabia and 5,000+ customer cards currently ride on that one signing setup.

The pricing is deliberately boring. Free forever covers up to 100 customers, 100 wallet messages a month, 1 stamp card, and 1 branch, with no credit card. Growth is 85 SAR a month for unlimited customers, up to 10 cards, 3 branches, and 5,000 messages. There's no per-card fee and no setup fee.

The trade-offs, stated plainly

Your pass is signed under Waya's Pass Type ID. The customer sees your shop's name as the pass title, your logo, and your colors, but the cryptographic issuer underneath is Waya. If you need passes signed under your own developer identity — say you already ship an iOS app and want everything in one namespace — a shared platform certificate isn't that, and no loyalty vendor's shared certificate will be.

You're also inheriting somebody else's uptime and renewal discipline. That's a real dependency and worth naming as one. The alternative is a calendar reminder of your own standing between your regulars and their stamps.

On competitors: most Saudi loyalty vendors issue genuine wallet passes too, because the certificate problem is identical for everyone and gets solved the same way. Their published prices as of August 2026 are Btaqa at 108, 250, and 380 SAR a month, OneCup at about 150 SAR a month, Watily at 149 SAR a month with loyalty bundled into a wider plan, and Niqati quote-based. Verify all of those with the vendor before deciding. The structural difference is the starting line: each of those begins with a paid subscription, while Waya begins at 0 SAR up to 100 customers with no card on file.

One thing no platform removes: somebody at your counter still has to scan the card. Waya needs no POS integration and no hardware, since staff scan from an ordinary phone using the web dashboard or the iOS merchant app. But a beautifully signed pass that nobody ever stamps is just a nice-looking file.