This interface enables webstore to query the status of the orders or payment transactions in Svea Payments.

How and when to use

Payment Status Query is recommended to be used even for orders that have been cancelled before paying or seem cancelled. That is, status should be queried even if the buyer has returned to the webstore using cancel or error return URL.

The first status query could be done for example one (1) or two (2) hours after the order was placed. This should tackle most situations. If Svea Payments does not know the status of the payment at that point, a call to corresponding bank’s status query interface is triggered.

In some rare cases, which we have seen happening, the status query to the bank never succeeds, but then one or two banking days later, Svea Payments receives the buyer’s money to the customer assets bank account. When that happens, Svea Payments marks the transaction as paid and from that point on the Payment Status Query API will report the order as paid. Therefore, for orders that stay in an unknown payment state, it could be a good solution to poll Svea Payments Payment Status Query for example once a day, for a period of a few banking days after the order was placed.

About response codes briefly

Some status codes (related to payment services that use Buyer’s Assistant) indicate that the webstore should react in some way:

• Response code 20: The buyer has paid the order but the delivery information has not yet been given or transmitted to Svea Payments. As soon as the delivery has been started or done, the delivery information should be given or transmitted to Svea Payments.

• Response code 91: The buyer has proposed a cancellation of the order. The proposal waits for the webstore's confirmation. Webstore should not confirm the cancellation until the buyer has returned the products. If the webstore had not delivered the products, the cancellation can be confirmed immediately. After the confirmation, the buyer will be fully refunded.

• Response code 92: The buyer has proposed a partial refund of the order. The proposal waits for the webstore's confirmation. Webstore should not confirm the change proposal until the buyer has returned the products. If the webstore had not delivered the products, the change proposal can be confirmed immediately. After the confirmation, the buyer will be refunded.

• Response code 93: The buyer has proposed a partial refund and return of some deliveries of the order. The proposal waits for the webstore's confirmation. Webstore should not confirm the change proposal until the buyer has returned the products. If the webstore had not delivered the products, the change proposal can be confirmed immediately. After the confirmation, the buyer will be refunded.

• Response code 95: The buyer has made a reclamation. The buyer and webstore must negotiate a solution after which the buyer can withdraw the reclamation. After this either party can make the appropriate changes to the order according to negotiated solution.

Please note that some of response code values are only applicable to Buyer’s Assistant (formerly known as “Satisfaction Guarantee”) payment services. Such response codes are marked with the following label: “(Buyer’s Assistant)"

Skip to contents in this page

Payment Status Query in different environments

Svea Payments production environment

When a payer returns from an internet bank or from another payment service to Svea Payments service, the payment is set as confirmed. After this, all the payment status query requests will get a confirming response regardless of whether the payer returns to the web store before or after the query message or whether the payer returns at all. If the payer has not yet returned from e.g. an internet bank to the Svea Payments service when the payment status query is made, Svea Payments inquires the payment status from the bank but only if the payer has had sufficient time for making the payment. If the payment is confirmed by the bank, Svea Payments confirms the payment to the web store. The exact response code of a payment confirmation depends on whether the Buyer’s Assistant or direct payment service is being used.

Svea Payments test environment

In the test environment the internet banks do not store the payment data and therefore Svea Payments can not verify bank payments in which the payer has not retuned to Svea Payments service from the bank. After the payer has returned from the internet bank to the Svea Payments service (from where the payer is instantly redirected to the web store), also the test payment is registered to Svea Payments and possible Payment Status Queries can now receive a payment confirmation.

If one wishes to test a status query for a payment that is still pending in the web store but is in fact paid, one needs to finalize the payment in the internet bank and let the web browser to proceed to the Svea Payments service but prevent it to redirect back to the web store. This way the payment will be confirmed in Svea Payments, but stays pending in the web store.

As the automatic redirecting from Svea Payments to the web store is instant, preventing the redirection requires special tools. With Firefox-browsers one can use e.g. the Tamper Data extension which (among other things) enables the user to allow or abort browser forwarding - e.g. from Svea Payments service to the web store.

Sandbox test page

While using Sandbox test credentials (in production or test environments) Svea Payments does not store payment event data and therefore the payment statuses can't be inquired either. For Payment Status Queries that use Sandbox test credentials Svea Payments service always responses with a random response code. Sandbox credentials should therefore be used only for validating the query message or connection to the Svea Payments service, but the received response codes should not be let to affect the order statuses in the web store.