Unlike the early days of ecommerce, today’s consumers want the freedom to pay the way the want to. Whether it’s using a digital wallet, when their offline, from a specific region, or with cutting-edge, alternative payment solutions in addition to credit cards! 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 have finer-grained control over your web properties. That’s where we come in -- Amazon Pay is here to illustrate how to make your payment solutions work for you.

Assessing your payment solutions

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

• Does the payment transaction process synchronously during the customer’s checkout experience, or can it be completed later on in an asynchronous or offline fashion?

• Is the payment solution really a stand-alone payment method that your customers can choose from as part of your existing checkout page, or is it meant to be its own full-featured checkout experience?

• How do you get notifications on the state of a transaction? Do they get pushed to your systems automatically, or do you need to poll and query (pull) for them?

• Can your customers grant you consent to save or re-bill their chosen payment instrument, or do they always have to initiate a new transaction themselves?

Considering this functionality can help you visualize 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. Instead, you can 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 – which is why some credit-card gateways only offer this sort of transaction.

Asynchronous payments (imagine Western Union where you physically hand over money or a check) on the other hand, are more useful when it’s not as important that a transaction happen ‘right now’ as it is that the transaction is inspected and approved. Amazon Pay supports this 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 Authorization that will send your systems a notification later on.

Payment notifications

Let’s talk notifications. The way a payment solution notifies you about a transaction is just as important as how it is processed! Depending on your infrastructure and security requirements, it can be important to have full control over inbound or outbound communications, by only polling for or ‘pulling’ that information yourself.

While this approach might be secure, not every payment solution out there supports businesses periodically sending API requests to its servers to get information on a transaction! It can be just as important to consider receiving ‘push’ notifications instead. These notifications are sent from your payment solution provider’s servers directly to an endpoint that you define. This allows you to step away from having to manage processes like ‘cron jobs’, and have a single endpoint that can have handlers (did someone say AWS Lambda functions?!) for all your payment types that support ‘push’ notifications.

Amazon Pay is here to support whichever approach makes sense for your infrastructure needs through its Instant Payment Notifications (push) and its transaction query APIs (pull). For more information on IPNs and learning how to process them, make sure and peruse our article on “The world of Instant Payment Notifications”!

Checkout design?

Two considerations focus on your customers’ experience. How a payment solution is presented to buyers can ultimately influence their decision to proceed with a purchase . It is important to know whether a solution is meant to be a stand-alone payment method (Pay with your credit card or with direct bank transfer) or if it is meant to take the place of an entire checkout experience (Amazon Pay).

Offering buyers an alternative and ‘quick’ / ‘express’ checkout earlier on in their journey allows them to make purchases when they want to – but you wouldn’t want to just start asking them for their credit-card information! It is equally important to make sure the options you provide your customers, match the capabilities of each payment solution – and that you only offer one type at the same time.

For example, you might want to offer Amazon Pay (which is primarily a checkout experience) along with another wallet-based checkout experience like PayPal Express, on an individual product page or as part of your customers shopping cart. This would let them buy that product right then and there. You might in turn want to offer a larger variety of stand-alone payment methods (credit cards, wallets, alternative payment methods) directly on the checkout or order-confirmation page, making sure that your customers can pay how they want.

Of course, Amazon Pay can also be used as a stand-alone payment method in the latter case, which means you can decide ‘where’ to surface it depending on your ideal customer experience! The most important thing though, is to make sure you surface the types of payments that make sense in your situation. Offering both a checkout-experience and a standalone payment method at the same time, in the same place, can be confusing to the customer and means you now have to handle two different ‘flows’ in your code!

Card-on-File?

Building on top of the idea that your customers’ should be able to pay when and how they want, the final consideration you should have is whether or not a payment solution allows for the colloquially-known ‘Card-on-File’ scenario. That term gets thrown around a lot in the world of payments, but for this blog, think of it as simply allowing your customers the opportunity to ‘consent’ to be billed later, possibly more than once, using whatever payment instrument they want. It’s important to know which of your desired payment solutions do or don’t have such functionality – particularly if your business aims to sell things on a recurring or subscription-type basis. Letting your buyers ‘save’ their desired payment information means that they can come back and check-out even faster than before, OR even let you bill them without them having to lift a finger – but it’s important to only surface this for the right reasons. Any fan of the Spiderman franchise will tell you, “With great power comes great responsibility”, and it is particularly true for being able to charge a customer ‘whenever’!

You can also offer customers the option to save their checkout details for ‘next time’ with Amazon Pay! Your customer will always be able to simply pick from their stored payment instruments linked to their Amazon.com account. We also offer Billing Agreements functionality that allows your customers to buy a subscription or another type of recurring purchase.

These Billing Agreements let your customer give you, the merchant, consent to bill them ‘whenever’. In this scenario, it’s important that you store the Billing Agreement ID in a secure database (I hear Aurora is great for this!) or within your subscriptions / recurring billing solution of choice. By keeping these IDs 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 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.. We here to support the way you architect your infrastructure, your security, or your customer experience – Amazon Pay just ‘works’ with it.