I'm seeking clarification on how Requirement 4.1 ("Card Issuers with a Mobile App must support In-App provisioning") applies when the card issuer uses a third-party mobile banking platform rather than a self-developed app.
Our situation:
- We are a small credit union (the card issuer)
- Our mobile banking app is provided by a third-party digital banking vendor (white-label, but branded with our name)
- Card processing is handled by a separate vendor
The ambiguity:
The Apple Pay Specifications define "Card Issuer Mobile App" as:
"The Card Issuer-branded, iOS software application made available on a Device that is used by such Card Issuer's customers to manage, administer, or use Cards."
Our mobile banking app meets this definition—it's branded with our name and used by our members to manage their accounts and cards. However, we don't develop or directly control the app; our digital banking vendor does.
The webinar FAQ stated: "Do we have to implement in-app provisioning? Yes, if you have an app."
Our digital banking vendor interprets this as not applying to them because they are "not the issuer." They've stated: "Apple's requirements are at the card-processor level... our credit unions and, by extension, we are not required to support Apple Pay's in-app provisioning."
Our card processor has indicated they will support in-app provisioning integrations but notes "this would be digital provisioning and we would need the digital banking vendor to work with us to enable."
Specific questions:
-
When a card issuer uses a third-party mobile banking app (branded for the issuer but developed/maintained by a vendor), does Requirement 4.1 apply?
-
If yes, who bears compliance responsibility—the issuer, the mobile app vendor, or both?
-
If the mobile app vendor does not implement in-app provisioning by January 15, 2026, what is the issuer's exposure? Does the issuer face suspension from the Program due to vendor non-compliance?
-
Is there an alternative compliance path under Requirement 4.8 (Web Provisioning) for issuers whose mobile app vendors cannot deliver in-app provisioning by the deadline?
This scenario likely affects hundreds of small financial institutions using shared digital banking platforms. Clarity on vendor vs. issuer responsibility would help the entire ecosystem prepare appropriately.
Thank you.
Hi @eknutsen,
You wrote:
[...] I'm seeking clarification on how Requirement 4.1 ("Card Issuers with a Mobile App must support In-App provisioning") applies when the card issuer uses a third-party mobile banking platform rather than a self-developed app. [...]
As a card issuer bound by the Apple Pay Issuer Functional Requirements, your institution carries contractual and compliance obligations that cannot be transferred or waived simply because a third-party vendor declines to act. The questions raised — including compliance responsibility, program suspension risk, and alternative provisioning paths — are legal and contractual in nature.
I strongly advise you to contact your legal counsel to:
- Review your Apple Pay issuer agreements and determine how Requirement 4.1 obligations apply to your institution specifically
- Assess your contracts with both your digital banking vendor and card processor to identify each party's responsibilities and any breach of contract exposure
- Evaluate your risk of program suspension in the event your vendor does not deliver in-app provisioning by the January 15, 2026 deadline
- Determine whether web provisioning under Requirement 4.8 constitutes a viable and permissible interim compliance path
- Advise on steps to document good-faith efforts and protect your institution in the event of vendor-driven non-compliance
Given that this situation may affect hundreds of similarly situated small financial institutions, obtaining clear legal guidance now is essential to protecting your institution and your members.
Cheers,
Paris X Pinkney | WWDR | DTS Engineer
