The scariest part of digital payments is not taking your first online purchase, maintaining complex systems, or even fraud. Nope, the stuff of product strategy nightmares is usually like this:
Biz Partner: “Last week we had a 10% drop in checkout conversion at payments – what happened?”
Payments PM: “There’s a new Chrome feature for embedded lending via ApplePay and/or GooglePay. We’re not compatible with it.”
Biz Partner: “How long will it take us to activate it?
Payments PM: “I’m not sure. At least a few weeks.”
Biz Partner: “Ugh, thanks for getting on it quickly … this is costing us $#%^@ a week; leadership is asking me daily about it”
Payments moves so quickly; can any product strategy survive the unpredictability of what will drive customer behavior next? Are there winning answers to payment’s complex system design questions? And the pressure is high: payments is the most mission-critical step (“getting the money”).
Both PaaS and PPaaS give you strong answers to system design questions, enhancing your payments product strategy. PPaaS also makes you less dependent on any PSP, further leveraging lean agile development to lower cost-of-change.
If you’re not familiar with PaaS & PPaaS – check out my previous article “Got PPaaS?” Read on to get more in-depth use cases of how PPaaS lowers the cost of change.
Navigating global payments diversity
Any effective payments product strategy must consider system design questions based on varying global payments regulations. For example, drastic changes came to Europe the last few years with PSD2 requiring all digital payments to have Strong Customer Authentication (SCA) – typically using two-factor authentication (2FA). Most leading PSPs (Stripe, Paypal, Square, etc) quickly provide lean agile development solutions – merchants only needed to add a few lines of code to support the needed 2FA interface appearing during checkout.
Simple enough, right? Why mess with the complexity of a PPaaS system? Consider this example: for merchants selling subscriptions, if they add a new PSP or switch PSPs, the SCA is reset. Customers must return to the merchant’s website to reauthorize subscription payments. When a customer takes a while to do this, or never does (both common), merchants suffer significant delays and losses in revenue.
This is a system design question – is there a way to preserve the SCA independently of the PSP? Here a PPaaS system provides a stronger product strategy than PaaS. A tokenized wallet integration stores the SCA in a PSP-agnostic vault. When the merchant uses a different PSP to process the transaction, the SCA most often carries over. Subscription revenue keeps flowing – no customer action required.
What will customers pay with next?
Today’s customers expect to be able to check out from any device with any payment method, many of which were unheard of until recently. Third-party wallets (GooglePay, ApplePay) and specific bank redirects have an increasing impact on the likelihood a customer completes payment. Embedded lending (BNPL, Buy Now Pay Later) is even newer – and yet predicted to be a multi-trillion dollar market within a few years.1 And which payment methods are most commonly used varies widely by geography. Keeping up raises overwhelming systems design questions, that require answers because of this truth:
Don’t give customers their preferred way to pay, and they’ll simply go buy from someone who does
Fortunately, PSPs offer a lean agile development solution here too – typically a configuration tool to turn on/off different payment methods and/or the ability to send payment method parameters when loading the payment module at runtime. With a PaaS integration, you can even support multiple PSPs and/or configurations of available payment methods: have your checkout flow decide – e.g., based on the customer’s payment method or geography) – which PSP’s payment module to load and/or edit which parameters you send it. These options are essential for your product strategy when your PSP doesn’t support a payment method you need or offers unfavorable rates for using the third-party wallet, bank redirect, and/or embedded lending most popular with your customers.
Unfortunately, this is not a sustainable way to answer the systems design questions. What started as one-at-a-time lean agile developments quickly becomes a duct-taped-together mess. Business logic is spread between different components in your system and PSP dashboard configuration settings. Payment method availability changes have to be made in multiple places. Cost of change increases and there’s high risk of mistakes and breaking parts of your payment system.
PPaaS’ product strategy magic shines here, providing a single place to put all payment methods business logic.
As new payment methods continue evolving, business logic changes are all in a single centralized digital payments platform module. When a new payment method enters the scene, you’re less constrained to when or if your current PSP(s) offer it. And there’s less risk of mistakes and regressions.
You can implement new payment methods as fast or faster as any competitor, keeping up with your customers’ preferred payment methods.
What to spend less while keeping up with the latest in digital payments tech?
We’d love to talk more about your digital payments product strategy and how you can better architect your digital payments systems for lean agile development. Let us help you more easily decide and move on the digital payments trends that best serve your business while minimizing the risk you’ll be stuck with when more change comes later.
Shoot me an email (paul.mack@integral.io) or sign up for a Integral Product Success Lab – our free Labs are a 1-2 hour session where we’ll facilitate and nerd out with you on your payments systems.
