iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Apple Pay and Google Pay ECv2 tokens are not interchangeable: each has its own envelope, trust chain, signature checks, key-recovery method, and cipher suite. Select the flow from the token’s protocol field, verify authenticity before using payment data, and perform transaction-level checks after decryption. A successful decrypt alone does not authorize a payment.
Start with the protocol field, not the wallet name
Apple documents two payment-token versions: EC_v1 and RSA_v1. Google’s merchant cryptography guide describes ECv2; Google says existing ECv1 implementations can continue to work, but enabling ECv2 payloads in production must be coordinated with Google. Apple’s EC_v1 and Google’s ECv2 are names for different protocols, not compatible versions of one format. Parse the token’s own version field and route it to the corresponding platform-specific verifier and decryptor. Apple’s format reference and Google’s merchant cryptography guide define those flows.
Also distinguish Google’s API version from its token protocol version: the API version describes the request and response structure, while protocolVersion selects the token’s cryptographic scheme. Google’s request reference identifies ECv2 for DIRECT protocol configuration. Google Pay request objects
The Tool Desk
Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →How the token envelopes differ
| Property | Apple Pay | Google Pay ECv2 |
|---|---|---|
| Outer fields | UTF-8 serialized JSON with data, header, detached PKCS #7 signature, and version. |
UTF-8 serialized JSON with protocolVersion, signature, intermediateSigningKey, and signedMessage. |
| Encrypted-message fields | data is Base64-encoded. The header includes publicKeyHash and transactionId, plus ephemeralPublicKey for EC_v1 or wrappedKey for RSA_v1; applicationData is optional. |
signedMessage contains encryptedMessage, ephemeralPublicKey, and tag. |
| Key recovery and encryption | Use the matching merchant key to restore a symmetric key, then use AES-256-GCM for EC_v1 or AES-128-GCM for RSA_v1. |
Use P-256 ECIES-KEM and HKDF-SHA256 to derive separate keys, authenticate with HMAC-SHA256, then decrypt with AES-256-CTR. |
These structures and cryptographic choices are specified in the Apple token format reference and Google merchant cryptography guide. Apple says most regions use ECC; RSA may be used in some regions where ECC is unavailable because of regulatory concerns. Do not assume that every Apple token uses EC_v1. Apple’s version documentation
#1 Best Overall
- 1️⃣ Take Control of Your Finances - Easily set monthly financial goals and track your income, savings, debts, and expenses. Say goodbye to budget chaos with this comprehensive financial organizer.
- 2️⃣ Effortless Bill Tracking - Features a detailed bill management system: paid & auto-paid checklist, unpaid bills, due dates, amounts due, amounts paid, and unpaid balances. Includes a monthly overview to keep your income, expenses, and balance in check.
- 3️⃣ Extra Pages for Versatile Planning - Bill payment organizer includes dedicated sections to save bank account details, track debt payoff, summarize yearly financial progress, brainstorm ideas, and jot down notes for added flexibility.
- 4️⃣ High-Quality Design for Daily Use - 128 pages with a large 8 x 10-inch (20.32 x 25.4 cm) format for easy reading and writing. Printed with sharp, clear layouts to ensure a top-tier user experience that stands out from competitors.
- 5️⃣ More Than a Financial Tool - This bill tracker notebook is not just about tracking; it’s about celebrating progress. Over four years, your entries will document milestones and serve as a cherished keepsake of your financial achievements.
Apple Pay: validate the signature before decrypting
For Apple tokens, the signature is detached from the encrypted data. Follow Apple’s documented checks and use the correct signed-field sequence for the version rather than applying one generic concatenation to both formats. The signature certificate must have the required OIDs and chain to Apple Root CA G3. Apple’s validation requirements
- Validate the certificate and signature. Check the required certificate OIDs and trust chain, then verify the signature over the fields in the order Apple specifies: for
EC_v1,ephemeralPublicKey,data,transactionId, andapplicationData; forRSA_v1, replaceephemeralPublicKeywithwrappedKey. Include the optional application data only as directed by the format. - Check signing time. Inspect the CMS signing time. Apple says a difference of more than five minutes from the transaction time may indicate a replay attack; treat this as a warning signal to investigate, not as a substitute for transaction-level replay protection.
- Select the merchant key. Match
publicKeyHashto the relevant merchant public-key certificate and corresponding private key, then restore the symmetric key. - Decrypt using the version’s parameters. Apple specifies a 16-byte zero IV and no associated authenticated data for both versions; use AES-256-GCM for
EC_v1and AES-128-GCM forRSA_v1. - Validate the transaction before processing it. Check that the
transactionIdhas not already been credited, and compare the decrypted currency, amount, and application data with the original payment request.
The decrypted Apple payment data can include a device-specific account number, expiration, currency, transaction amount, payment-data type, cryptogram, and ECI. Treat these as payment inputs to validate against the transaction context, not as proof that the payment is authorized. Apple payment-token fields and validation
Google Pay ECv2: verify Google’s signing chain, then authenticate and decrypt
Google’s ECv2 token is signed and encrypted. Its payload may represent a PAN or a device PAN with cryptogram information. Google describes a verification sequence that begins with Google’s signing keys and ends with an expiration check on the decrypted message. Google’s ECv2 processing guide
Recommended Free Tools
- Fetch current Google root signing keys. Use a non-expired root key to verify the signature on
intermediateSigningKey, and check that the intermediate key itself has not expired. - Verify the signed message. Validate the payload signature with the verified intermediate key before relying on the message contents.
- Derive the decryption and authentication keys. ECIES-KEM on NIST P-256 derives a shared secret. HKDF with SHA-256, no supplied salt, and 512 derived bits produces two 256-bit keys: one for encryption and one for message authentication.
- Authenticate before decrypting. Verify
tagwith HMAC-SHA256 and compare the result in constant time. Only after it matches should the encrypted message be decrypted with AES-256-CTR, a zero IV, and no padding. - Reject an expired message. Check the decrypted
messageExpirationbefore using the payment credentials.
Google strongly recommends its Tink paymentmethodtoken library for the ECv2 verification and decryption steps. The guide says this library is available only in Java; teams using other languages should not assume that this particular implementation is available there or substitute an incomplete cryptographic flow. Google’s library guidance
Decryption is not a fraud decision. Google says its validation and fraud checks do not replace the merchant’s own risk management; retain the transaction checks appropriate to your integration after validating the token. Google Pay request objects and DIRECT requirements
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Google DIRECT has eligibility and key-maintenance requirements
DIRECT means the merchant handles payment credentials rather than using a supported gateway for that handling. Google requires DIRECT merchants to be PCI DSS compliant as validated by a Qualified Security Assessor and to operate servers equipped to handle credentials securely. Third-party gateway or processing providers serving merchants are not eligible for DIRECT. Google recommends a supported gateway when the merchant does not meet the stated prerequisites. Google Pay DIRECT requirements
Rank #4
For DIRECT, Google requires encryption-key rotation annually and allows a three-month grace period. During a rotation, support both the new and old private keys; retain the old private key for eight days after removing the old public key. Google also requires updated PCI documentation during rotation and says it may stop fulfillment requests if keys are not rotated. Build the overlap and documentation work into the rotation plan rather than treating key replacement as a single cutover. Google’s key-rotation requirements
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Fix the driver behind crashes, sound loss and screen glitches3Repair Windows errors before they cause bigger problemsGoogle’s guide, last updated 2026-02-20 UTC, says its current production root key is valid until 04/14/2038 under normal circumstances, except in the event of key compromise. Because root-key status is operationally volatile, verify the live guide and current key material when implementing or maintaining a verifier. Google’s current signing-key guidance
Best Value
The cited Apple format reference specifies selecting the merchant key using publicKeyHash, but does not establish a universal merchant-key rotation interval. Set Apple key lifecycle procedures from the applicable Apple integration requirements and your operational controls rather than borrowing Google DIRECT’s schedule.
Quick Recap
Implementation decision rule
- Route by the token’s protocol/version value: Apple
EC_v1orRSA_v1, versus GoogleECv2. - Keep platform-specific parsing, trust validation, signature verification, key recovery, and cipher parameters separate; matching words such as “EC” do not make the formats compatible.
- Authenticate before using decrypted credentials, then check expiry, replay status, amount, currency, and the original request context as applicable to that platform.
- For Google DIRECT, confirm eligibility and plan recurring key rotation and overlap before launch. Use a supported gateway if the DIRECT prerequisites are not met.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
