Swedbank Pay Checkout – Summary
If you have read this far, you should now be done with the basic integration of Swedbank Pay Checkout. Congratulations! Read on to check items on the check list to ensure that your integration complies with our Best Practices.
A completed integration against Swedbank Pay Checkout should adhere to a set of best practice criteria in order to successfully go through Swedbank Pay’s integration validation procedure. These best practices are mentioned below.
- The Checkin and Payment Menu components (the two
<iframe>elements) must be separate (one must not replace the other).
- The Checkin must be completed before any shipping details are finalized, as
the Checkin component provides shipping address via the
- If a browser refresh is performed after the payer has checked in, the payment
menu must be shown even though
onConsumerIdentifiedis not invoked.
consumerProfileRefreturned in the response from the
POSTrequest to the
consumersresource must be included in the
POSTrequest to the
paymentUrlmust be included in the
POSTrequest of the Payment Order to ensure the best possible handling of retried payments.
- When the contents of the shopping cart changes or anything else that affects
the amount occurs, the
paymentordermust be updated and the Payment Menu must be
- Features not described on this page must not be used, although they are
available in the API. Flags that can be turned to
truemust be kept
falseas described in this standard setup documentation.
- When the payer is checked in, he or she must be identified appropriately in the Payment Menu (stored credit cards must be visible for the credit card payment instrument, for instance).
orderReferencemust be sent as a part of the
paymentordersand must represent the order ID of the webshop or merchant website.
- The integration needs to handle both one and two phase purchases correctly.
- All of the operations
Reversalmust be implemented.
- The transaction callback must be handled appropriately.
- Problems that may occur in Swedbank Pay’ API must be handled appropriately.
- Your integration must be resilient to change. Properties, operations, headers, etc., that aren’t understood in any response must be ignored. Failing due to a something occurring in a response that your implementation haven’t seen before is a malfunction that must be fixed.
paymentUrlmust be placed on a page where it can invoke the same
paymentUrlso the same original payment view can be initiated. The state identifier is the ID of the order, shopping cart or similar that has the URL of the Payment or Payment Order stored.