How Long Does It Take to Integrate Apple Pay and Google Pay as a Card Acquirer

An Apple Pay and Google Pay integration timeline for a card acquirer will likely take between three and eight months to complete. The length of time will depend on the tokenization system that the processor uses and the payment channels that are included in the integration.

What drives the integration timeline

One of the biggest factors that will impact the integration timeline is whether or not the processor already has MDES and VTS connections live and in operation. If they do, the acquirer will be able to cut months of setting that up, certifying it, and moving forward with the integration process. However, if the processor does not have these connections in place, there will be some time for that setup and certification before the acquirer can begin.

The second of the main factors is the payment schemes to be integrated into the system. Apple Pay and Google Pay can be integrated with either Visa cards or Mastercard cards, or both. Therefore, there will be two certification packages to run through the schemes, both in parallel, if the processor and the acquirer can handle such a heavy certification package.

The third main factors that impact the timeline is the number of channels into which the acquirer will be integrating Apple Pay and Google Pay. For instance, if only the web channels are to be integrated with Apple Pay and Google Pay, that will be significantly faster than if in-app payments and POS payments are also to be integrated.

Prerequisites for Apple Pay and Google Pay as a card acquirer

An acquirer will need to have an active license for both Visa and Mastercard. This license can come through either principal membership with the card schemes or through BIN sponsorship from an entity that is a licensed sponsor of those card brands.

Direct enrollment with Apple Pay or Google Pay is the following prerequisite to integrating with either wallet platform. For instance, Apple requires that the entity enrol in the Apple Pay merchant program. Google Pay requires that the entity have access to the Google Pay for Business application and API, which is obtained through the Google Pay & Wallet Console.

The last of the prerequisites is the processor of the acquirer. The processor will have to have support for a token gateway, live MDES and VTS connections, and be PCI DSS Level 1 compliant to accept tokenized transactions on behalf of the acquirer. Any acquirer that attempts to implement Apple Pay or Google Pay with a processor that does not have these features will have to wait until the processor has implemented these systems before it can begin to implement their own systems.

A typical integration schedule

An Apple Pay and Google Pay integration timeline will pass through three main stages: the discovery and contracting stage, the technical integration stage, and the certification and go-live stage. Each of these stages can happen in succession or in part simultaneously. The total length of time for the project to go from start to finish will likely fall somewhere around twelve to twenty weeks.

Discovery and contracting (2 to 4 weeks)

The discovery and contracting stage will include everything that occurs before any code is written or implemented. The acquirer will finalise what they will include in the integration, evaluate which processor will be the best for their merchants, and contract with them. The length of this stage will be shorter if the acquirer is more specific about the integration details than if the specifics of that integration are to be determined during the contracting phase.

Technical integration (6 to 10 weeks)

The technical integration stage is the longest stage of the process. The acquirer will connect their systems to the processor's token gateway and ensure that the processor has live MDES and VTS connections. If the acquirer is only integrating with web channels, they will begin to implement Apple Pay on the Web and the Google Pay API for Web during this stage.

3DS 2 needs explicit attention during this phase. Tokenized transactions still flow through 3DS 2, and the evidence sent to the issuer differs from a standard PAN transaction. Misaligned 3DS 2 fields are a common source of certification rework, so this work belongs in the build phase rather than at the end.

Certification and go-live (4 to 6 weeks)

Certification means running the official Visa and Mastercard test scripts against the integration in their certification environments. Each script exercises a specific transaction scenario, including purchase, refund, partial reversal, decline handling, and 3DS flows, and the output has to match the expected response exactly.

After the scheme certification clears, a pilot merchant runs user acceptance testing with real cards and real wallet devices. Once the pilot transactions settle correctly and reconcile against scheme reports, the integration is ready to open up to broader merchant rollout.

Fastest vs slowest paths

The fastest path for the acquirer to implement Apple Pay and Google Pay will be through a processor that already has live MDES and VTS connections, which is only certifying one channel (typically web-based channels) for the acquirer, and has a pilot merchant ready to perform user acceptance testing after the system is implemented.

The slowest path will be for the acquirer to work with a processor that has not yet built out their MDES and VTS connections, who must implement Apple Pay and Google Pay into three channels (web, in-app, and POS), and who is onboarding several pilot merchants for certification.

While the typical integration will sit somewhere in the middle of these two timescales, three months will be achievable with the correct processor and integration details. Eight months or more will be realistic if there are foundational systems that must be built prior to the implementation of the Apple Pay and Google Pay channels.

Common challenges in the certification process

The biggest overruns of Apple Pay and Google Pay integration timelines for acquirers will occur during the certification stage for the various schemes.

Test script failures

Two of the most common failed test scripts during certification are those related to partial refunds for tokenized cards and 3DS 2 frictionless flows.

For acquirers who have built their system for refund and partial reversal functions with the legacy PAN of the card, there will be challenges with this process when it is performed on a tokenized card. The same logic will have to be used with the tokenized PAN, which can make for an adjustment period for acquirer developers.

The second of the two most common failures of the test scripts is with the implementation of the 3DS 2 frictionless flow. During certification, the 3DS 2 system will review the logs of the transactions that were performed to verify that the implementation of the frictionless flow was correctly implemented by the acquirer.

Any discrepancies between the implementation as described in the documents and the transactions in the logs will result in the certification package being sent back to the acquirer for rework.

Documentation and audit gaps

In addition to the test scripts, the certification packages will be reviewed against the documentation of the implementation that was submitted with the certification documents. Additionally, the audit logs of the test scripts will be reviewed against the documentation.

Any gaps between the two will result in the certification package being returned to the acquirer for rework.

Scheme review queues

Finally, the certification package will be sent to the card schemes for review by their representatives. There is no commitment from either Mastercard or Visa to deliver their certification representatives to an acquirer within a specific timeframe.

Therefore, an estimated two to three weeks of certification will factor in the length of the review queue by the schemes' representatives.

While the certification stage for most acquirers will last between four and six weeks, a two to three-week buffer will account for the review queue should the certification representative take longer than estimated.