techtipspaymentarchitecture-banner.jpg:eu

Designing your businesses payment experience

Learn about the way Amazon Pay maintains their customer obsessed approach to payments as their product has evolved alongside other solutions.

Unlike the early days of ecommerce, today’s consumers want the freedom to pay the way they want to – using a variety of different payment methods. Developers and Product Managers not only have to understand those varied ways to pay, but also how to get them to work in concert with one another. It can be a pretty daunting task. In fact, that’s why many businesses opt to use ready-made ecommerce or shopping-cart solutions instead! But, if you’re like me, you might want to build a more customisable solution. That’s where we come in -- Amazon Pay is here to illustrate how to make sure all your payment integrations work together when building out your new web property.

Assessing your payment solutions

When looking at your payment solutions, it can be a helpful first step to categorise them by what they do and how they do it.

  • Synchronous vs. asynchronous: When does the customer learn if their payment is successful? Are customer notified immediately -- synchronised with the checkout experience? Are they notified via an email at some point after checkout is complete? How will you handle declined transactions, and when?
  • Stand-alone payment method vs. checkout experience: When does the customer first get to interact with the payment solution? Does the customer have an option to quickly check out from a product page through a streamlined checkout experience? Is your payment solution part of your existing order confirmation and checkout page alongside other stand-alone payment methods such as Credit Card or ACH?
  • Push vs. pull notifications: How do you get notifications on the state of a transaction? Do customers get pushed to your systems automatically, or do you need to query (pull) for them?
  • One-time vs. recurring payments: Can your customers grant you consent to save or re-bill their chosen payment instrument (e.g. for a subscription), or do they always have to initiate a new transaction themselves?

Consider these functions to help visualise your integrations in a way that allows for the development of pattern-based, scalable integrations. It can also help you move beyond having to build custom handlers, checkout pages, and business logic for each payment scenario you support. Focus on building only the code that’s necessary to handle each payment method’s specific fields, APIs, and endpoints.

Synchronous vs. Asynchronous payments

Clarify whether a transaction is happening asynchronously and, or synchronously to dictate how you communicate to your customers, and when you can start fulfilling their order. Synchronous payments (happen ‘in real time’) are attractive when you need to offer customers a quick way to buy your products and want to make sure they know right away whether their transaction was successful. Synchronous payments are the type of transaction credit-card solutions offer. If you’re not worried about too many declines, or you have repeat customers who are purchasing lower order-value products, this is the payment type for you!

Asynchronous payments that take place partially ‘offline’, or outside the checkout experience, are more useful when verification and approval is more important than immediacy. This can be useful if you’re selling high-value items (e.g. luxury apparel, furniture, etc.) and your customers aren’t expecting to get billed right away. You’ll be able to rest easy knowing that the response from your payment solution provider is verified and correct, rather than quick.

Amazon Pay supports both of these situations by letting you request a synchronous authorization that happens right away, returning a status as part of its API response, or by requesting an asynchronous authorisation that will send your systems a notification later on. You can even chain these two type payment experiences together to perform a synchronous authorisation first, and only if the result is a decline, follow it up with an asynchronous authorisation to make sure.

Payment notifications

The way a payment solution notifies you about a transaction is just as important as how it is processed! Are you receiving a “Push” notification similar to what you’d receive on your phone when the item you just purchased has shipped? Or, are you constantly polling an API endpoint similar to opening up your phone’s shopping app and checking to see if it’s shipped?

Depending on your infrastructure and security requirements, it can be important to have full control over inbound or outbound communications, by only polling that information yourself. While this approach might be secure, not every payment solution out there supports repeatedly sending API requests to its servers to get information on a transaction!

Instead, if your payment solution provider supports “Push” notifications, then you can opt to have their servers directly send updates to an endpoint that you define. Instead of ‘Cron Jobs’, you are free to have a single endpoint that can have individual handlers for your payment solutions.

Amazon Pay can support the approach that makes sense for your infrastructure needs through Instant Payment Notifications (push) and transaction query APIs (pull). For more information on IPNs and learning how to process them, read our post on “The world of Instant Payment Notifications”.

The customer experience

How a payment solution is presented to buyers can influence their final decision to purchase. Two major considerations to keep in mind are; can it provide a streamlined checkout experience earlier on in the customer’s journey and does it allow for recurring payments?

Offering your customers an alternative or quick checkout option earlier on (e.g. on your individual product pages, or in your shopping cart) is a good idea for those who know what they want. However, it’s also important to make sure that each payment solution is a good fit for where customers are in the journey.

For example, you might want to offer Amazon Pay as an alternative way to just buy one of your products and ‘go’. This would let them go through the Amazon Pay checkout experience immediately, without having to proceed through the lengthier checkout flows needed when offering other ‘types’ of payment methods directly.

Of course, Amazon Pay can also be used as a stand-alone payment method – only surfacing the option to choose from a stored payment method when your customer has already completed their journey. Offering both of those types of payment experiences in the same place at the same time, means a customer could have to select their shipping, billing, and payment information twice. As this is far from ideal, make sure to consult how each of your payment solutions is made available to the customer.

Recurring payments

When it’s time to finish checking out, the final consideration is whether or not a payment solution supports Recurring Payments. This consideration is important whether you’re only selling subscription-based products, or a mixture of both subscriptions and one-time items. Imagine the pain a customer would feel, having reached the checkout page with their cart full of your products, only to try and checkout with their preferred payment method and be notified that it isn’t supported! Make sure you only surface the ‘right’ payment methods, dependent on what’s in your customer’s cart, to reduce friction.

With Amazon Pay, a customer already has access to their saved payment methods and we also offer a way for them to consent to being billed in the future using that payment method. By associating a token to that consent, you’ll now need to store the token in a secure database or within your subscriptions solution of choice. By keeping these Amazon Pay tokens in the same logical format and location as your other tokens, permissions, or agreements – you can manage your customers’ subscriptions from one central location no matter what payment method they opted to use.

Your code is your business

If you’re coming to the conclusion that Amazon Pay provides a lot of flexibility, instead of committing to a single integration pattern or method….you’re right! We believe that at the end of the day, your code is your business and we are here to provide a checkout experience that delights both you and our shared customers. Whether that’s by supporting your choice of notification methods, or by giving your customers the freedom to be billed later, we’re here to help.

For more tips on making the most out of your Amazon Pay integration, check out 7 tactics to optimise your custom Amazon Pay integration.