Amazon Pay - API

After a user signs in via Amazon Pay, we can make API calls against the order. The first step is to initialize order data and store it to a quote transfer object using the Quote updater classes. These classes work in a similar way to transaction handlers. However, they only retrieve information from Amazon (if necessary) and then save it to a Quote.

There are three steps for initializing a new order:

Only the first step uses an API call while the other two are only about initializing.

The updater class for retrieving buyer data is called GuestCustomerDataQuoteUpdater. It uses a related adapter called ObtainProfileInformationAdapter, to make an API call and store data into the Quote transfer.

We have this call instead of taking current user data to create a separation between Spryker and Amazon accounts and enable the ability to make an order without a Spryker account.
If a logged in user places an order, the order would be still assigned to him and visible in the Customer area.

Once a buyer chooses a shipment address from the Address widget, a Javascript callback is triggered.

We notify the server side that the user has changed their shipping address.

Then we use the Facade method addSelectedAddressToQuote to return the updated quote object and save the updated quote.

Now the quote contains updated address information and it's possible to retrieve available shipment methods.

The Spryker OS provides a Shipment module and uses method getAvailableMethods() to retrieve the shipment methods list and send it back to the customer.

Once shipping options are updated a buyer can choose one. Usually, shipment methods affect the total price of the order and it must be recalculated using the Calculation module.

Once all necessary information is saved into Quote, an order is ready to be placed.

First, perform all related API calls and then persist an order in the database.

All API related jobs are covered by only one Facade method confirmPurchase() which encapsulates five Amazon Pay API calls to be executed one after another:

Each API call is handled by a transaction handler object. In order to call more than one transaction, the module provides TransactionSequence class. TransactionSequence encapsulates an array of transaction objects. A developer can easily replace single transaction with sequence or replace transaction objects within transaction sequence objects.

Here is an example of an execute method for the collection:

foreach ($this->transactionHandlers as $transactionHandler) {
    $amazonpayCallTransfer = $transactionHandler->execute($amazonpayCallTransfer);

    if ($amazonpayCallTransfer->getAmazonpayPayment()->getResponseHeader() &&
        !$amazonpayCallTransfer->getAmazonpayPayment()->getResponseHeader()->getIsSuccess()) {
        break;
    }
}

return $amazonpayCallTransfer;

Once a transaction is finished successfully, we pass the updated quote transfer to the next transaction. If the transaction fails, we return the current one and it contains all information about an error.

The authorization API call is configurable and it reflects the whole payment process.

The first important setting is the transaction_timeout that defines the maximum number of minutes allocated for the Authorize operation call to be processed, after which the authorization is automatically declined and you cannot capture funds against the authorization.

Zero value means that authorization result has to be returned immediately and it is synchronous authorization. For the asynchronous authorization, the value must be above zero but less than maximum possible 1440.

Another important setting is CaptureNow. It can only be true or false and if set to true then both requests - Authorization and Capture will be done in one step, within Authorize API call.

Amazon Pay documentation defines a workflow which has to be implemented on a merchant side.

In some cases, declined payment involves additional API calls. This is why there is an additional transaction collection called HandleDeclinedOrderTransaction. This call goes after the Authorization step and encapsulates two transaction objects:

GetOrderReferenceDetailsTransaction which was used previously and CancelOrderTransaction.

When all previous steps return a positive response and authorization is accepted it returns transfer object without any modifications. If payment is declined because of wrong payment method - there's nothing to do on a server side.

If the reason is different, we can check the state of an order using GetOrderReferenceDetailsTransaction.

If it is open, then the order must be canceled with a CancelOrderTransaction call.

The rest of decline flow includes logic determining where to redirect a buyer. In sandbox mode, for each test account, Amazon provides fake payment methods for emulating error API responses.

Even if a response has status code 200 it still may contain Constraint(s) in the response body.

There is one special constraint related to selected payment method PaymentMethodNotAllowed. If it occurs (rarely) the buyer should be redirected to the same page with address and payment widgets and be able to choose a different payment method and all other order parameters as well.

Unlike synchronous authorization it is impossible to get the result of authorization in the response. Authorization objects stay in Pending state until authorized. Capture and Refund requests can also be processed in the same way and Amazon provides Internet Payment Notification (IPN) in order to notify the shop about the new status of any asynchronous request. IPN message is an HTTP request with some special Amazon-related headers and the body which is an XML string containing all data. The merchant has to specify URL for receiving and processing IPN messages.

The module provides two Facade's methods:

• convertAmazonPayIpnRequest(array $headers, $body) for converting an Amazon request (which is HTTP headers and body) to the transfer object. For each type of IPN request, we provide a related transfer object and method. convertAmazonPayIpnRequest() returns one of them.
• handleAmazonPayIpnRequest(AbstractTransfer $ipnRequestTransfer) should be called. It has AbstractTransfer type for its argument and it works with all types of IPN related transfer objects. A typical flow of a successful flow usually involves pending statuses of authorization and capture requests.

Therefore, related IPN messages have to be received and processed correctly. For retrieving the same information Amazon also provides GetAuthorizationDetails and GetCaptureDetails functions and in Spryker OS it is possible to update the pending statuses with State machine buttons. Once the button is clicked, the shop makes a related API call, receives a response and if the state is not pending then it updates order status according to the response message. The final status of a success flow is "capture completed". After that only Refund is available and refund workflow is asynchronous only and works in a similar way as asynchronous authorization.

The more tricky case is authorization declined workflow. It is similar to synchronous decline which was described above but everything goes asynchronously and involves additional IPN messages. First of all, Authorization IPN comes with "Declined" state of authorization status. Another important information here is ReasonCode and it affects all further steps of the process. For the reason codes TransactionTimedOut and AmazonRejected the order simply goes to authorization declined state but for the InvalidPaymentMethod the customer has to change the payment method to the correct one. In this case, order receives authorization suspended status and Amazon sends two additional IPN messages: OrderNotification with the state "Open" comes in after payment method is changed by buyer and Authorization notification as a result of authorization of a new payment method. If new payment method passes authorization successfully then order goes to the auth open state and it is possible to request a capture. In both decline cases, it is important to notify the buyer about it by email since it's the only one way for him to know that payment is not possible. The text of the email letter has to be different for InvalidPaymentMethod case.

Another tricky moment about asynchronous flow is "Authorization expired" situation. Each time the shop requests capture in asynchronous mode, it should check the current status of an authorization. Capture is only possible when the status of authorization is "Open". If authorization has status Closed and ReasonCode is either ExpiredUnused or SellerClosed then an order should be reauthorized with CaptureNow setting enabled.