Onboard Digital Wallets (Playbook)
- Apple Pay and Google Pay should be your first payment optimization project. 50%+ lower fraud, 3-5% higher auth rates, and it doesn't change your processing cost
- Most processors (Stripe, Braintree, Adyen) have wallet support built in - enabling it takes hours, not weeks, if you're already on their platform
- Apple Pay requires domain verification and an Apple Pay merchant identifier. Google Pay is a lighter setup, but don't launch it without testing on a real Android device
- Watch the wallet payment mix after launch. Adoption usually climbs to 20-40% of mobile transactions inside 30-60 days, and if yours doesn't, button placement is why
Apple Pay and Google Pay transactions see 50%+ lower fraud and 3-5% higher auth rates than raw card entry. If you're not accepting them, you're leaving money on the table. This playbook gets you live in 2-4 weeks.
Timeline: 2-4 weeks, or faster if there's a dashboard toggle at your processor.
Workflow Overview
| Phase | Key Tasks |
|---|---|
| Processor Setup | Confirm wallet support, Apple Pay Merchant ID, Google Pay console access |
| Integration | Hosted or custom checkout, Apple Pay + Google Pay code |
| Testing | Test matrix (iOS, Android, desktop), all devices, refund flows |
| Launch | Enable production, track metrics (auth, fraud, conversion), optimize placement |
You'll need a processor account that supports digital wallets, access to your gateway dashboard, an Apple Developer account for Apple Pay, Google Pay Business Console access for Google Pay, and either developer time or a gateway that handles the integration for you.
Trigger Criteria
Use this playbook when:
- You don't accept Apple Pay or Google Pay
- Mobile conversion is below desktop
- Auth rates on mobile are lagging
- You want to reduce CNP fraud without adding friction
Week 1: Processor Setup
Step 1: Confirm Processor Support
| Processor | Apple Pay | Google Pay | Notes |
|---|---|---|---|
| Stripe | Native | Native | Just enable in dashboard |
| Braintree | Native | Native | Minimal config needed |
| Adyen | Native | Native | Enable per merchant account |
| Worldpay | Supported | Supported | May need separate enrollment |
| First Data | Supported | Supported | Check terminal compatibility |
Checkpoint: Processor confirms wallet support is enabled on your account.
Step 2: Apple Pay Merchant ID
- Log into Apple Developer account
- Create Merchant ID (Certificates, Identifiers & Profiles)
- Generate Payment Processing Certificate
- Upload certificate to processor/gateway
- Domain verification (add file to /.well-known/)
Checkpoint: Apple Pay Merchant ID active, domain verified.
Step 3: Google Pay Setup
- Register in Google Pay Business Console
- Request production access
- Configure merchant info (name, country)
- No certificate required (easier than Apple Pay)
Checkpoint: Google Pay production access approved.
Week 2: Integration
For Hosted Checkouts (Stripe Checkout, PayPal, etc.)
Most hosted checkouts auto-enable wallets. Verify:
- Check your checkout config
- Enable Apple Pay / Google Pay toggles
- Test on iOS (Apple Pay) and Android (Google Pay)
Checkpoint: Wallet buttons appear on mobile checkout.
For Custom Checkout
If you're building a custom checkout (not using hosted checkout), your developer will need to:
Apple Pay Integration
- Check if Apple Pay is available on the customer's device
- Show the Apple Pay button only when supported
- Configure supported networks (Visa, Mastercard, Amex)
- Handle the payment response and send to your processor
What to tell your developer: "Use the Apple Pay JS API. Our processor has documentation and test cards."
Google Pay Integration
- Initialize the Google Pay client for production
- Check if Google Pay is ready to pay
- Configure allowed card networks and auth methods
- Connect to your payment gateway for tokenization
What to tell your developer: "Use the Google Pay API. Configure it with our processor's gateway ID."
Checkpoint: Wallet buttons appear; test transactions succeed in sandbox.
Week 3: Testing
Test Matrix
| Scenario | Apple Pay | Google Pay |
|---|---|---|
| Safari iOS | Test | N/A |
| Chrome iOS | N/A | Test |
| Safari macOS (Touch ID) | Test | N/A |
| Chrome Android | N/A | Test |
| Chrome Desktop (with phone) | N/A | Test |
Test Cases
- Successful payment on iOS device
- Successful payment on Android device
- Payment with saved card in wallet
- Refund processes correctly
- Wallet shows in transaction details
- Auth rate tracking captures wallet type
Checkpoint: All test cases pass in production with real cards.
Week 4: Launch and Monitor
Step 1: Enable in Production
- Remove feature flags / enable for all users
- Ensure buttons appear on mobile and desktop (where supported)
- Monitor error logs for first 24 hours
Step 2: Track Metrics
Set up reporting to compare:
| Metric | Card Entry | Apple Pay | Google Pay |
|---|---|---|---|
| Auth rate | Baseline | Target +3-5% | Target +3-5% |
| Fraud rate | Baseline | Target -50% | Target -50% |
| Checkout conversion | Baseline | Target +5-10% | Target +5-10% |
Step 3: Optimize Placement
Best practices for wallet buttons:
- Above the fold on checkout
- Before card entry form (not hidden below)
- Equal visual weight to card option
- On product pages for express checkout (optional)
Checkpoint: Wallets live in production; metrics tracking enabled.
Success Criteria
You're done when:
- Apple Pay and Google Pay both accepting live transactions
- Metrics show auth rate improvement vs card entry
- Mobile conversion stable or improved
- No increase in support tickets
Scale Callout
| Volume | Considerations |
|---|---|
| Under $100k/mo | Hosted checkout with wallet support is fastest path; prioritize this over custom integration |
| $100k-$1M/mo | Track wallet adoption rate; A/B test button placement; ensure both iOS and Android covered |
| Over $1M/mo | Wallet-specific auth analysis; push wallets in marketing; consider express checkout on PDPs |
Where This Breaks
- Processor doesn't support wallets. Switch processors or use third-party tokenization.
- Apple domain verification fails. Check .well-known file is accessible; no redirects.
- Low adoption after launch. That's usually button placement. A/B test position and size.
- Auth rate same as cards. The improvement varies, and it's still worth it for the fraud reduction.
- Desktop Safari users confused. Requires Touch ID Mac or iPhone nearby; consider tooltip.
Next Steps
After wallets are live:
- Track adoption rate: What % of customers use wallets? Set targets for growth
- A/B test placement: Experiment with button position and size to drive adoption
- Add express checkout: Consider wallet buttons on product pages for one-click purchase
- Measure fraud impact: Compare fraud rates between wallet and card-entry transactions
- Enable PayPal/Venmo: If not already, consider additional wallet options
Related
- Auth Optimization - Improving approval rates
- EMV & Contactless - Tokenized payments security
- Benchmarks - Industry wallet adoption
- Digital Wallets - Wallet fundamentals
- Checkout Conversion - Conversion optimization
- Fraud Prevention - Wallet fraud reduction
- Increase Auth Rates - Auth optimization playbook
- Processor Management - Processor wallet support
- 3D Secure - Authentication interaction
- Cards - Card network fundamentals
- Payments Metrics - Tracking wallet performance
- Payment Change Checklist - Testing wallet integration