Wallet
Functions to add passes, loyalty cards, tickets, boarding passes, coupons, and similar to the device's built-in wallet app Google Wallet on Android and Apple Wallet on iOS.
Your backend creates the actual pass (a signed Google Wallet JWT on Android, a signed .pkpass file on iOS); WebToNative's job is handing that ready-made pass to the OS wallet app and reporting back whether it was saved.
You'll need to import the javascript file in your website before starting from this link.
Platform support:
isSupportedandaddPasseswork on both Android and iOS.getNameis Android-only.getPasses,checkPassExists,removePass, andreplacePassare iOS-only — see Platform Differences.
Read this before you write error-handling code. The two platforms use different field names and nesting for callback responses (success vs. a nested data/error), and iOS's addPasses resolves several "unsuccessful" outcomes (cancelled, already-in-wallet) through the success shape, not the failure one. Skimming the tables below and skipping straight to the JSON examples in Callback Response Format will save you a debugging session.
Before You Start
WebToNative doesn't create or sign passes for you — you need one already built per platform:
Android (Google Wallet): a signed JWT from the Google Wallet Issuer API, or the
https://pay.google.com/gp/v/save/<jwt>save link Google returns for one.iOS (Apple Wallet): a signed
.pkpassfile, either as a URL your server hosts or as base64-encoded data — built with a Pass Type ID from your Apple Developer account.
Building and signing that pass — setting up your Issuer account and pass classes on Android, or generating and signing the .pkpass bundle on iOS — is covered step by step, with backend code examples, on Creating & Signing Wallet Passes. Come back here once you have a JWT (Android) or a .pkpass URL/base64 string (iOS) in hand.
Setting Up Wallet
Go to your WebToNative dashboard → Add-ons → Wallet and enable it.
No further credentials are required on the WebToNative side — pass creation and signing happens on your own backend.
JavaScript API Reference
isSupported
Checks whether the device has a wallet available to add passes to.
Parameters:
callback
Function
No
Callback function invoked with the response.
Callback Response — Android:
Android error codes for this call: NOT_INITIALIZED, AVAILABILITY_CHECK_FAILED, UNEXPECTED_ERROR.
Callback Response — iOS:
iOS always resolves this call successfully (there is no failure shape for isSupported on iOS) and nests the result under data, alongside an extra canAddPass flag not present on Android — check data.isSupported there, not a top-level field.
The two platforms do not return the same shape: Android is flat (isSupported at the top level, and it can fail), iOS is nested under data (with an extra canAddPass, and it never fails). Branch on platform if you need the exact field, or just treat response.isSupported ?? response.data?.isSupported as the supported flag.
getName
Returns the name of the wallet product available on the device (e.g. "Google Wallet").
Android only. The callback is never invoked on iOS.
Parameters:
callback
Function
No
Callback function invoked with the response.
Callback Response:
addPasses
Adds one or more passes to the device wallet. This is the main function of the add-on — works cross-platform, but the pass format each platform expects is different, so give each platform the field it understands:
Android: put the pass string(s) — signed JWT, or a
pay.google.com/gp/v/save/...save link — inpasses.urls/base64sare used as a fallback only whenpassesis omitted entirely — if you pass a non-emptypassesarray alongsideurls/base64s, the latter are ignored rather than combined; usepassesfor clarity.iOS: use
urlsfor a hosted.pkpassfile, orbase64sfor base64-encoded.pkpassdata.passesalso works on iOS — each entry is auto-classified as a URL or base64 string and routed accordingly. If you pass both non-emptyurlsandbase64stogether, onlyurlsis used;base64sis ignored.
Parameters:
passes
String[]
No*
Android: signed JWTs or Google Wallet save links, one per pass. iOS: any mix of .pkpass URLs or base64 strings — auto-detected.
urls
String[]
No*
iOS: .pkpass file URLs. Android: used only as a fallback when passes is omitted.
base64s
String[]
No*
iOS: base64-encoded .pkpass data. Android: used only as a fallback when passes is omitted.
callback
Function
No
Callback function invoked with the response.
* Provide at least one of passes / urls / base64s.
Callback Response: see Callback Response Format — the shape differs by platform.
getPasses
Reads passes already in the wallet — every pass of a given type, or one specific pass.
iOS only.
Parameters:
passTypeIdentifier
String
No
Paired with serialNumber to look up one specific pass.
serialNumber
String
No
Paired with passTypeIdentifier.
passType
String
No
Use "all" for every pass, or a specific pass type to filter by.
callback
Function
No
Callback function invoked with the response.
Callback Response:
The type field on this response is always "getWalletPasses" (not "getPasses") — filter on that if you're listening for it outside the SDK's own callback registration. The response shape also differs depending on which lookup you made:
checkPassExists
Checks whether a pass is already in the wallet — either by identifier, or by handing over the pass itself (its URL or base64 data).
iOS only.
Parameters:
passTypeIdentifier
String
No*
Paired with serialNumber.
serialNumber
String
No*
Paired with passTypeIdentifier.
url
String
No*
Alternatively, the pass's .pkpass URL.
base64
String
No*
Alternatively, the pass's base64-encoded data.
callback
Function
No
Callback function invoked with the response.
* Provide either passTypeIdentifier + serialNumber, or url, or base64.
Callback Response:
removePass
Removes a pass from the wallet — either by identifier, or by handing over the pass itself.
iOS only.
Parameters:
passTypeIdentifier
String
No*
Paired with serialNumber.
serialNumber
String
No*
Paired with passTypeIdentifier.
url
String
No*
Alternatively, the pass's .pkpass URL.
base64
String
No*
Alternatively, the pass's base64-encoded data.
callback
Function
No
Callback function invoked with the response.
* Provide either passTypeIdentifier + serialNumber, or url, or base64.
Callback Response:
replacePass
Replaces a pass already in the wallet with an updated version — e.g. after a loyalty card's points balance changes.
iOS only.
Parameters:
url
String
No*
The updated pass's .pkpass URL.
base64
String
No*
Alternatively, the updated pass's base64-encoded data.
callback
Function
No
Callback function invoked with the response.
* Provide url or base64.
Callback Response:
Callback Response Format
Every Wallet callback response carries a type and a success boolean (not isSuccess — both platforms use success). Where the payload beyond that lives — top-level, under data, or under error — differs by platform and by function, and addPasses in particular differs by platform in ways worth reading carefully.
Android — single pass
Android — multiple passes
All succeeded:
One or more failed — data is keyed by the index of the pass in the array you sent, true for a pass that saved and an error object for one that didn't:
Android error codes: NOT_INITIALIZED, AVAILABILITY_CHECK_FAILED, INVALID_PASS, CANCELED, SAVE_ERROR, EMPTY_BATCH, BATCH_IN_PROGRESS, UNEXPECTED_ERROR.
iOS — single pass
A single pass always resolves through the success shape for every expected outcome — added, cancelled by the user, or already in the wallet — and only ever fails (the success: false shape) for a genuinely invalid pass or an unexpected native error. data.status and the failure shape are mutually exclusive: a response never has both.
data.status (success shape only) is one of: added, cancelled, already_exists, unsupported. It never contains invalid_pass or error — those two outcomes always come back through the failure shape instead, with a SNAKE_CASE error.code from the table below (e.g. INVALID_PASS_DATA, UNABLE_TO_CREATE_ADD_CONTROLLER, NO_PRESENTER_AVAILABLE, PASS_LIBRARY_UNAVAILABLE) rather than the literal string "invalid_pass" or "error".
iOS — multiple passes
All succeeded — minimal response:
Partial or total failure — note this is the success: false shape, and the summary is nested under error, not data:
Each failedPasses entry has an error message string plus, when it can be determined, the batch index of the failed item (falling back to an identifier string like "urls[2]" if the index can't be parsed) — there is no separate code field in these entries.
Every other function (isSupported, getName, getPasses, checkPassExists, removePass, replacePass) reports { type, success, ...data } on success and { type, success: false, error: { code, message } } on failure, following the same pattern as above for its platform — see each function's own Callback Response section above for the exact shape of data.
Platform Differences
isSupported
✅
✅
getName
✅
❌
addPasses
✅
✅
getPasses
❌
✅
checkPassExists
❌
✅
removePass
❌
✅
replacePass
❌
✅
Implementation Checklist
WebToNative Dashboard
Your Backend
Your Website
Frequently Asked Questions
Last updated