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, f
or 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 Satisfaction Guarantee payment services) 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 indeed are only applicable to Satisfaction Guarantee payment services. Such response codes are marked with the following label: “(Satisfaction Guarantee)"
Response code values
| Response code | Short description | Description |
|---|---|---|
| 00 | Not paid. | Not paid. If additionally pmtq_amount = 0,00: The order does not exist OR it has been created but no payment method have been chosen. If additionally pmtq_paymentmethod and pmtq_amount are present in the response: An order has been created and a payment method have been chosen, but Svea Payments does not know (yet) if the payment has been or will be successful or not. |
| 01 | Query failed | Exception. Failed to retrieve the transaction information. |
| 20 (Satisfaction Guarantee) | Paid, waiting for delivery | The customer has paid the transaction but the delivery information has not yet been given or transmitted to Svea Payments. As soon as the delivery has been done or started, the delivery information should be given or transmitted to Svea Payments. |
| 30 | Paid and... ...being delivered OR ...inspection period effective OR ...not yet settled to webstore | Paid and... ...the delivery is under way OR ...the order has been delivered to the buyer and the inspection period is effective. OR ...the inspection period has passed or is not applicable (i.e. Direct payment service) but the order has not yet been settled to webstore. |
| 40 | Settled to webstore | The order has been settled to webstore. The money amount will land on the vendor’s bank account within a couple of workdays (depending on the source and target banks). This is the final state for the transaction. That is, the transaction is closed. |
| 91 (Satisfaction Guarantee) | Buyer has proposed a cancellation | 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. |
| 92 (Satisfaction Guarantee) | Buyer has proposed a partial refund | 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. |
| 93 (Satisfaction Guarantee) | Buyer has proposed a partial refund and return of some deliveries | 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. |
| 95 (Satisfaction Guarantee) | Buyer has made a reclamation. | 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. |
| 99 | Cancelled | The payment transaction and order has been cancelled. Webstore has either cancelled it or confirmed buyer's cancellation proposal. Also Svea Payments may have cancelled the order if requested. Important! In case of Direct payment services (e.g. eMaksut), this does not concern Bank payments. |
Delivery status code values
Delivery status code values are only relevant in case of Satisfaction Guarantee services (e.g. Maksuturva Gold).
| Status code | Short description | Description |
|---|---|---|
| 00 | Code received | We have received a tracking code. Delivery not yet found. |
| 10 | Being delivered | Delivery has been verified using a logistics company’s system, or a certain time has passed since receiving information about an untraceable delivery. |
| 20 | Waiting for pickup | Logistics company has indicated that the delivery has arrived in the office where the order recipient can pick up the delivery. This status may also indicate that the delivery is currently being delivered to the recipient’s delivery address. |
| 80 | Delivered | The recipient has received the order. |
Payment Status Query in different enviroments
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 Satisfaction Guarantee 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.