Apple Pay, Google Pay, and Now Wero — How Many Payment Methods Can a Mobile App Actually Support?

General
1

The Checkout Screen Is Becoming a Wall of Logos

I lead mobile engineering at a company that processes payments in 30+ countries. My team has been dealing with payment method proliferation for years, and the Wero announcement just added another item to an already overwhelming list.

Let me share the mobile engineering perspective on what happens when yet another payment method enters the market.

The Current State of Mobile Payments

Here’s what our checkout screen already supports:

  • Cards: Visa, Mastercard, Amex, Discover (via tokenization)
  • Digital wallets: Apple Pay, Google Pay, Samsung Pay
  • Bank transfers: SEPA, iDEAL (Netherlands), Bancontact (Belgium), Przelewy24 (Poland)
  • BNPL: Klarna, Afterpay, PayPal Pay Later
  • Regional: PIX (Brazil), UPI (India), Alipay, WeChat Pay
  • Crypto: (we removed this after 0.1% adoption, but the code is still there haunting us)

That’s 15+ payment methods before adding Wero. Each one requires:

  1. Native SDK integration — most payment methods provide iOS and Android SDKs that need to be independently maintained
  2. UI components — buttons, logos, loading states, error handling, all following each provider’s brand guidelines
  3. Deep linking — redirecting to banking apps for authentication and handling the return flow
  4. State management — tracking payment status across app lifecycle events (app backgrounding, force quit, network loss)

The SDK Bloat Problem

This is the part that keeps me up at night. Each payment SDK adds:

  • Binary size: Apple Pay SDK is lightweight (built into iOS), but third-party payment SDKs can add 2-10 MB each to your app binary. Our payment module alone is now 47 MB of our 120 MB app size.
  • Dependency conflicts: Multiple SDKs using different versions of the same underlying libraries. Last quarter we spent two weeks resolving a conflict between Klarna’s SDK and our analytics framework.
  • Startup time impact: Each SDK initialized at app launch adds 50-200ms. With 8 payment SDKs, that’s potentially 1.6 seconds of payment-related initialization before the app is responsive.
  • Maintenance burden: SDK updates, breaking changes, deprecation notices. My team spends roughly 20% of our time just maintaining payment SDK integrations.

The UX Challenge: Paradox of Choice

Research consistently shows that more payment options don’t always mean higher conversion. There’s a point where the checkout screen becomes overwhelming and users abandon.

Our A/B testing data:

  • 3 payment methods: 78% checkout completion rate
  • 5 payment methods: 82% completion (optimal)
  • 8+ payment methods: 76% completion (decision paralysis)

The question with Wero is: does it replace an existing method (like SEPA bank transfers) or does it add to the pile? If it’s additive, we need smart logic to show the right payment methods to the right users.

What Wero Integration Looks Like on Mobile

Based on what I’ve seen from the German launch, Wero’s mobile flow is:

  1. User selects “Pay with Wero” in the merchant’s app
  2. App redirect to the user’s banking app for authentication (SCA)
  3. User authenticates via biometric/PIN in their banking app
  4. Return to merchant app with payment confirmation

This is essentially the same flow as iDEAL and Bancontact — app-to-app redirection. From an engineering perspective, it’s manageable but introduces the classic redirect flow pain points:

  • App not installed: What if the user’s banking app isn’t on their phone? Fallback to web authentication is clunky.
  • Universal links / App links: These are notoriously unreliable across OS versions. iOS 17 changed universal link behavior and broke several of our payment redirect flows.
  • Background/foreground lifecycle: User authenticates in banking app, then the OS kills our app in the background due to memory pressure. When they return, they see a fresh app state with no payment context. This happens more often than you’d think on older devices.
  • Timeout handling: How long do we wait for the user to complete authentication in their banking app? 60 seconds? 5 minutes? What if they get distracted?

My Framework for Payment Method Prioritization

Here’s how I decide whether to invest in a new payment method:

Criteria Weight Wero Score
Addressable users in our markets 30% 8/10 (48.5M, growing to 130M)
SDK quality and documentation 25% 3/10 (too early to evaluate)
Conversion rate impact vs. existing methods 20% 5/10 (unknown, likely neutral initially)
Merchant demand from our clients 15% 7/10 (strong signal from European clients)
Engineering cost relative to alternatives 10% 4/10 (moderate, redirect-based)

Weighted score: 5.55/10 — that puts Wero in the “monitor and prototype” category, not the “integrate immediately” category.

What Would Change My Calculus

Three things would push Wero to the top of my integration queue:

  1. A high-quality, well-documented iOS and Android SDK with sandbox testing
  2. Proof that Wero drives incremental conversion (not just cannibalization of existing bank transfer methods)
  3. Regulatory mandate requiring Wero acceptance (this would override all other considerations)

Until then, I’m recommending my team build the abstraction layer (as Alex and Luis discussed) and wait for Wero’s SDK maturity to catch up with its user growth.

Fellow mobile engineers — how are you handling payment method proliferation? Anyone found a good pattern for dynamic checkout that doesn’t degrade to a scrollable list of logos?

2

The UX/Design Perspective: Your Checkout Screen Needs an Information Architecture Overhaul

Maria, your A/B testing data on checkout completion rates is gold. Let me build on it from a design perspective because this is a pattern I’ve been wrestling with across multiple products.

The “Wall of Logos” Is a Design Failure, Not a Payment Problem

When I see a checkout screen with 15+ payment method logos, my first reaction as a designer is: this is an information architecture failure. We’re presenting a flat list of options when we should be presenting a structured decision tree.

The Smart Checkout Pattern

Here’s what the best checkout experiences are moving toward:

Level 1: Intelligent Default
Show the user’s most likely payment method prominently — based on their country, device, previous behavior, and the transaction amount. For a German user with Wero installed, show Wero first. For a French user on iPhone, show Apple Pay.

Level 2: Categorized Alternatives
Below the default, show 2-3 alternatives grouped by type:

  • “Other wallets” (expandable)
  • “Pay by card” (expandable)
  • “Pay later” (expandable)

Level 3: Full List
A “More payment options” link that expands to show everything else.

This pattern reduces the visible choices from 15+ to 1 primary + 3 categories, which maps to your optimal 4-5 visible options for maximum conversion.

Wero-Specific UX Considerations

The redirect-to-banking-app flow you described creates specific UX challenges:

1. The “Where did I go?” Problem
When users get bounced to their banking app, they lose context. The return flow needs a strong visual anchor — immediately show them what they’re paying for, the amount, and a confirmation state.

2. The Loading State Gap
Between “user left our app” and “user returned with confirmation,” there’s a dead period where we have no idea what’s happening. I’d recommend:

  • A persistent notification or PiP (Picture-in-Picture) overlay showing payment in progress
  • A clear “waiting for bank confirmation” state with a cancel option
  • Graceful timeout messaging that doesn’t blame the user

3. Brand Trust for a New Payment Method
Wero is unknown to most consumers outside Germany. The checkout UI needs to build trust:

  • Show the Wero logo alongside the user’s bank logo (“Pay with Wero via Deutsche Bank”)
  • Include a brief explainer tooltip: “Secure instant payment directly from your bank account”
  • Display security badges and ECB/EPI backing

The Dynamic Checkout Solution

To answer your closing question — the pattern I’ve seen work best for dynamic checkout:

  1. Server-side payment method ordering — your backend determines which methods to show based on user context, and in what order
  2. Progressive disclosure — start with 3-4 methods, reveal more on demand
  3. Remember preference — once a user pays with Wero, make it their default for future transactions
  4. Contextual eligibility — only show payment methods the user can actually use (don’t show Wero to a US user)

The technical implementation of this dynamic ordering is non-trivial but it’s the right investment. Maria, your framework for evaluating payment methods should include a “checkout UX impact” criterion — does adding this method improve or degrade the overall checkout experience?

3

Product Prioritization: When to Say “Not Yet” to a Payment Method

Maria, your prioritization framework is one of the most practical things I’ve seen in this entire Wero discussion. Let me add the product strategy layer.

The Replacement vs. Addition Question

You asked whether Wero replaces an existing method or adds to the pile. From a product perspective, this is the question.

In Germany, Wero is effectively replacing Giropay (which is being discontinued) and partially replacing SEPA bank transfers for consumer payments. In the Netherlands, it could eventually replace iDEAL (though iDEAL is deeply entrenched). In France, it overlaps with Carte Bancaire’s domestic network.

If Wero replaces existing methods, it’s actually a net simplification:

  • Remove Giropay SDK (-5 MB binary)
  • Replace with Wero SDK (+? MB binary)
  • Net result: potentially fewer payment methods to maintain

If Wero is additive (running alongside existing methods for years), it’s the worst case for your team — more SDKs, more testing, more maintenance, with uncertain ROI.

The Product Manager’s Dilemma

Here’s what I’d tell the PM managing the payment checkout:

Don’t frame this as “should we add Wero?” Frame it as “what’s our European payment strategy for 2026-2028?”

That strategy should answer:

  1. Which European payment methods do we consolidate around?
  2. What’s our migration path from legacy methods (Giropay, potentially iDEAL) to Wero?
  3. At what Wero adoption threshold do we promote it above cards in checkout?
  4. How do we measure success — conversion rate, transaction cost, or client satisfaction?

The Platform Strategy Play

Maya’s point about server-side payment method ordering is exactly right. The real product investment isn’t in adding Wero — it’s in building the intelligent checkout orchestration layer that can:

  • A/B test payment method presentation
  • Optimize for conversion by market
  • Dynamically adjust to new payment methods without app updates
  • Provide analytics on payment method preference trends

This is the platform play. Once you have intelligent checkout orchestration, adding or removing Wero (or any payment method) becomes a configuration change, not an engineering project.

My Product Recommendation

  1. Q2 2026: Build the checkout orchestration layer (this benefits all payment methods)
  2. Q3 2026: Integrate Wero through your payment processor (when available) — not direct integration
  3. Q4 2026: A/B test Wero placement in German market
  4. 2027: Expand to France, Belgium based on German data

Your 5.55/10 score for Wero is fair for right now. But I’d bet that score hits 7.5/10 by end of 2026 as SDK maturity improves and merchant demand crystallizes. Build the infrastructure now so you can move fast when the score crosses your integration threshold.

4

The Technical Integration Complexity: A Developer’s War Story

Maria, I feel your pain on the SDK bloat problem. Let me share some patterns that have worked for me and where Wero fits in.

The Payment SDK Architecture I Wish I’d Built Sooner

After integrating my fifth payment method, I finally learned the lesson and built a proper abstraction. Here’s the pattern:

// Payment method interface - all methods conform to this
interface PaymentMethod {
  id: string;
  canProcess(context: PaymentContext): boolean;
  initialize(): Promise<void>;
  createPayment(request: PaymentRequest): Promise<PaymentResult>;
  handleCallback(data: CallbackData): Promise<PaymentStatus>;
}

// Lazy-loaded payment modules
const paymentRegistry = {
  'wero': () => import('./methods/wero'),
  'apple_pay': () => import('./methods/apple-pay'),
  'google_pay': () => import('./methods/google-pay'),
  'card': () => import('./methods/card'),
  // ... etc
};

// Only load SDKs for methods the user can actually use
async function getAvailableMethods(context: PaymentContext) {
  const eligible = Object.entries(paymentRegistry)
    .filter(([id]) => isEligible(id, context));
  
  return Promise.all(
    eligible.map(async ([id, loader]) => {
      const module = await loader();
      return module.default;
    })
  );
}

The key insight: lazy-load payment SDKs based on eligibility. Don’t initialize the Wero SDK for a US user. Don’t load Alipay for a German user. This alone cut our payment module initialization time by 60%.

The Redirect Flow Problem (and a Solution)

Your pain points about app-to-app redirect are real. Here’s the pattern we use to handle it reliably:

// Before redirecting to banking app
async function initiateWeroPayment(paymentId: string) {
  // 1. Persist payment state to local storage AND server
  await persistPaymentState({
    paymentId,
    status: 'pending_authentication',
    timestamp: Date.now(),
    returnUrl: buildDeepLink(paymentId),
  });
  
  // 2. Register for app lifecycle events
  AppState.addEventListener('change', (state) => {
    if (state === 'active') {
      // App returned to foreground - check payment status
      reconcilePaymentState(paymentId);
    }
  });
  
  // 3. Redirect to banking app
  await Linking.openURL(weroAuthUrl);
}

// When app returns to foreground
async function reconcilePaymentState(paymentId: string) {
  const localState = await getPersistedState(paymentId);
  const serverState = await checkPaymentStatus(paymentId);
  
  // Server is source of truth
  if (serverState.status === 'completed') {
    showSuccessScreen(serverState);
  } else if (Date.now() - localState.timestamp > TIMEOUT_MS) {
    showTimeoutScreen(paymentId);
  } else {
    showWaitingScreen(); // Still pending
  }
}

The critical detail: always persist payment state before redirecting, and always reconcile with server state on return. Don’t trust the callback URL alone — it can be lost if the OS kills your app.

Binary Size Mitigation

For the SDK bloat problem, a few practical strategies:

  1. Dynamic frameworks on iOS: Use dynamic linking so payment SDKs are loaded on demand, not at app startup
  2. Module federation on Android: Use dynamic feature modules for payment SDKs
  3. Web-based fallback: For payment methods used by <5% of users, consider a WebView-based integration instead of native SDK
  4. Server-driven UI: Render the checkout screen from server-provided configuration, so adding a payment method doesn’t require an app update

For Wero specifically, if the flow is redirect-based (similar to iDEAL), you might not even need a native SDK. A well-implemented redirect flow with proper state management could work with just URL handling — zero additional binary size.

Bottom Line

Maria, I agree with your “monitor and prototype” assessment. But I’d start the prototype now — build the abstraction layer, implement the redirect flow pattern, and test with the German sandbox when available. That way, when the SDK matures and the business case strengthens, you’re a sprint away from production, not a quarter.