This document is being actively revised
- OmniToken set up is required for eProtect
- The same eProtect account / credentials created for eCommerce will work for Android Pay
- ISV/App must be registered with Google
- eProtect must be configured with Google/merchant app identifiers (contact: Joe Canning, Melissa Green, or Denisse Lopez)
- ISV must integrate and certify with eProtect for Android Pay
Vantiv_Ecomm_Solution_for Android_Pay_V1.0: The preferred method involves you sending certain Vantiv specific parameters to Google. The response from Google® includes a Vantiv paypageRegistrationId, which you use normally in you payment transaction submission to Vantiv.
page 3 needs to be updated to include how to send payments to Mercury / Integrated Payments
Partial Auth / Partial Shipments NEEDS TO BE COVERED IN THE APPLE PAY AND ANDROID PAY FAQ
Bradley, Alex (Litle Co.) <Alex.Bradley@Vantiv.com>
We… sort of do this. As Jim and Stefan point out, we don’t support the network feature of having a merchant explicitly perform partial shipment auths, which requires them to correctly indicate that auths are “1 of 3”, “2 of 3”, etc. When partial captures come in we do follow a partial-reserval/partial-capture/re-auth flow along the lines they indicate, and the re-auths do get flagged as Partial Shipment (with the networks that support that flag)… but the partial shipment auths we generate don’t send either the cryptogram or a reference to the original auth, so I’m not sure how they would be tied together on the network side. We expect those partial shipment auths to succeed with a network token only if they match the original amount and merchant, and that’s what we saw in our testing with the network. If that requirement weren’t in place, you could mark every transaction as partial shipment and circumvent the cryptogram entirely. If there is another way that these auths are supposed to tie back to the original transaction, I’m not aware of it.