All Systems Operational
Acquiring of Card Transactions ? Operational
Card Authorization ? Operational
Clearing & Settlement ? Operational
Payment Solutions ? Operational
Instore Card Payments Operational
m/ecom Card Payments ? Operational
Swish ? Operational
Vipps ? Operational
Pay Later ? Operational
MobilePay ? Operational
Trustly ? Operational
Web Portal's Operational
Merchant Portal ? Operational
Consumer Portal ? Operational
eCom Admin ? Operational
PosPay WebReports ? Operational
CAM - IssuerAdmin ? Operational
CAM - UserPortal ? Operational
MediPay - MerchantPortal ? Operational
VAS Operational
Medipay Operational
APM Operational
Multipay - Mobile checkout Operational
GiftCard Operational
Valuecodes / Coupons Operational
Topup codes Operational
FuelCard Operational
FuelCard STIP Operational
FuelCard SAF Operational
RetailCard Operational
Operational
Degraded Performance
Partial Outage
Major Outage
Maintenance
Scheduled Maintenance
Maintenance of payment UI Feb 27, 2024 08:00-08:30 CET
We will be doing maintenance of the UI for a few payment methods in the payment menu, both in the external integration and the production environments.
No disturbances are anticipated as a result of the maintenance.

The following payment methods are scheduled for maintenance:

Swish
External integration - 27th of February
Production - 5th of March

Trustly
External integration - 5th of March
Production - 12th of March

Invoice
External integration - 12th of March
Production - 19th of March

If you have any questions or notice any problems, please do not hesitate to contact us via the regular support channels.

Posted on Feb 23, 2024 - 09:55 CET
In accordance with directives from Visa and Mastercard, we will be implementing 2 different types of limitations in the amount of successive reattempts of a previously failed transaction using either a
recurence- or unscheduledtoken that can be done using creditcard based payment methods. This limitation has up until now been handled by Swedbank Pay Acquiring, but will now be
handled earlier in the transaction process - enabling us to provide better and clearer response messages through the eCommerce-api.


One such limitation will be limiting the amount of successive reattempts of a previously failed transaction that can be done using creditcard based payment method within a specified period

The limitation in question varies based on the brand of the card, and are as follows:

Mastercard - 10 failed payment attempts allowed during a period of 24 hours.
Visa - 15 failed payment attempts allowed during a period of 30 days.

Note that all of the attempts has to get a failed response for the limit quota to be added to - if a transaction goes through successfully, the quota is reset.


The other limitation that will be implemented is in the case that Visa or Mastercard gives such a response that is flagged as "Do Not Retry" in accordance to Visa and Mastercard regulations.
This response is given in the cases that they deem the transaction to never be possible to be valid - as an example, if the card no longer exists, and thus there is no point in retrying.

In these cases, the card will be blocked immediately and no further attempts are allowed.

Both of these limitations are based on the combination of the acquiring agreement that the transaction was initiated from, and the PAN of the card that was used. That is, a card might be blocked because of
"Excessive Reattempts" at a particular merchant, while being allowed more reattempts at another. Please note that in the case a new card is issued in place of an old expired one, the new card usually keeps
the same PAN - meaning that if the old card was blocked, the new one will be as well (until the period resets). This marks the importance of having such a logic in place that limits reattempts before the
block actually takes place - this is where the new, clearer response messages will help.


When it comes to Excessive Reattempts, the new response messages will be returned if the quota for the period gets to 5 attempts remaining, as follows:

{
"type": "https://api.payex.com/psp/errordetail/creditcard/suspensionwarning",
"title": "SuspensionWarning. The card might be blocked.",
"status": 403,
"detail": "5 attempts left before the card is blocked.",
"problems": [{
"name": "ExternalResponse",
"description": "Forbidden-AuthenticationRequired"
}, {
"name": "SuspensionWarning",
"description": "5 attempts left before the card is blocked."
}, {
"name": "AUTHENTICATION_REQUIRED",
"description": "Acquirer soft-decline, 3-D Secure authentication required, response-code: O5"
}, {
"name": "Component",
"description": "pospay-ecommerce-financial-service"
}
]
}

Should more attempts be tried, and the transaction fail, the number of remaining attempts will update accordingly.


Once the card is blocked, the following responses will be given, depending on if the card in question is Visa or Mastercard:

Mastercard:
{
"type": "https://api.payex.com/psp/errordetail/creditcard/dailylimitexceeded",
"title": "Daily attempt limit is exceeded.",
"status": 403,
"detail": "The attempt is rejected after trying multiple times with same token.",
"problems": [{
"name": "REJECTED_BY_POSPAY_DAILY_LIMIT",
"description": "Intent with intentId 85ac3576-1e69-4aef-a066-84a0e6dcfa61, agreementId 80d0244c-2b15-4719-8ab1-ed83eddfee61 was suspended after exceeding the rolling 24 hour constraint of 10 attempts"
},
  {
"name": "Component",
"description": "pospay-ecommerce-financial-service"
}
]
}


Visa:
{
"type": "https://api.payex.com/psp/errordetail/creditcard/monthlylimitexceeded",
"title": "Monthly attempt limit is exceeded.",
"status": 403,
"detail": "The attempt is rejected after trying multiple times with same token.",
"problems": [{
"name": "REJECTED_BY_POSPAY_MONTHLY_LIMIT",
"description": "Intent with intentId 80456a1d-1cb1-429b-bf4e-8e1313362800, agreementId 3a47c702-7963-4915-9567-e1bce06d20dd was suspended after exceeding the rolling 30 day constraint of 15 attempts"
},
  {
"name": "Component",
"description": "pospay-ecommerce-financial-service"
}
]
}



The new responses for "Do Not Retry" will be as follows

The card being blocked, and no further attempts are allowed:
{
"type": "https://api.payex.com/psp/errordetail/creditcard/acquirererrordonotretry",
"title": "Do not retry.",
"status": 403,
"detail": "The attempt is rejected.",
"problems": [{
"name": "ExternalResponse",
"description": "Forbidden-AcquirerErrorDoNotRetry"
}, {
"name": "REJECTED_BY_ACQUIRER_DO_NOT_RETRY",
"description": "TOKEN04.ERR_FLG received in response, response-code: 05"
}, {
"name": "Component",
"description": "pospay-ecommerce-financial-service"
}
]
}


Furthermore, a new response is added, being returned in the case where the transaction is declined, but might be accepted after modifications:
{
"type": "https://api.payex.com/psp/errordetail/creditcard/acquirererrormodificationsrequired",
"title": "Modifications required.",
"status": 403,
"detail": "The attempt is rejected. Modifications required.",
"problems": [{
"name": "ExternalResponse",
"description": "Forbidden-AcquirerErrorModificationsRequired"
}, {
"name": "REJECTED_BY_ACQUIRER_MODIFICATIONS_REQUIRED",
"description": "TOKEN04.ERR_FLG received in response, response-code: 05"
}, {
"name": "Component",
"description": "pospay-ecommerce-financial-service"
}
]
}





In addition to the new responses shown above, the following will be added to more clearly show that a specific token is non-existant. These will, as an example, be returned as a response to a request for a previously
deleted token.


{
"type": "https://api.payex.com/psp/errordetail/paymentorders/paymenttokeninactive",
"title": "Payment token is inactive",
"status": 422,
"instance": "https://api.payex.com/psp/probleminstance/00-2fc18bd40743401596bf2de3b51ab16d-bfebd4ae81ea8423-01",
"detail": "The given UnscheduledToken is inactive.",
"problems": [{
"name": "UnscheduledToken",
"description": "The given UnscheduledToken is inactive."
}
]
}




{
"type": "https://api.payex.com/psp/errordetail/paymentorders/paymenttokeninactive",
"title": "Payment token is inactive",
"status": 422,
"instance": "https://api.payex.com/psp/probleminstance/00-2fc18bd40743401596bf2de3b51ab16d-bfebd4ae81ea8423-01",
"detail": "The given RecurrenceToken is inactive.",
"problems": [{
"name": "RecurrenceToken",
"description": "The given RecurrenceToken is inactive."
}
]
}

Posted on Feb 14, 2024 - 16:05 CET
Past Incidents
Feb 24, 2024

No incidents reported today.

Feb 23, 2024
Resolved - This incident has been resolved.
Feb 23, 14:41 CET
Investigating - We are currently experiencing a service disruption at third party. Our external provider/supplier is investigating the issue. Thank you for your patience.
Feb 23, 12:19 CET
Feb 22, 2024
Resolved - This incident has been resolved.
Feb 22, 12:47 CET
Update - We are experiencing a problem with a 3rd party payment processor. We are still awaiting a fix for the issue.
Feb 22, 11:17 CET
Identified - We are currently experiencing a service degradation. We are working to restore the service as soon as possible. Thank you for your patience
Feb 22, 10:30 CET
Resolved - This incident has been resolved.
Feb 22, 08:54 CET
Investigating - Verifone are currently having issues with clearing files which will cause delays with payouts to some customers.
Sorry for any inconvenience this may cause.

Feb 21, 08:06 CET
Feb 21, 2024
Resolved - This incident has been resolved.
Feb 21, 22:55 CET
Update - We are still awaiting a fix for this issue.
Feb 21, 21:21 CET
Update - We are still awaiting a fix for this issue.
Feb 21, 17:19 CET
Update - We are experiencing a problem with a 3rd party payment processor. We are still working to fix the issue.
Feb 21, 15:19 CET
Identified - We are currently experiencing a service degradation. We are working to restore the service as soon as possible. Thank you for your patience
Feb 21, 12:23 CET
Completed - The scheduled maintenance has been completed.
Feb 21, 11:00 CET
In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary.
Feb 21, 10:00 CET
Scheduled - In accordance with directives from Visa and Mastercard, we will be implementing 2 different types of limitations in the amount of successive reattempts of a previously failed transaction using either a
recurence- or unscheduledtoken that can be done using creditcard based payment methods. This limitation has up until now been handled by Swedbank Pay Acquiring, but will now be
handled earlier in the transaction process - enabling us to provide better and clearer response messages through the eCommerce-api.


One such limitation will be limiting the amount of successive reattempts of a previously failed transaction that can be done using creditcard based payment method within a specified period

The limitation in question varies based on the brand of the card, and are as follows:

Mastercard - 10 failed payment attempts allowed during a period of 24 hours.
Visa - 15 failed payment attempts allowed during a period of 30 days.

Note that all of the attempts has to get a failed response for the limit quota to be added to - if a transaction goes through successfully, the quota is reset.


The other limitation that will be implemented is in the case that Visa or Mastercard gives such a response that is flagged as "Do Not Retry" in accordance to Visa and Mastercard regulations.
This response is given in the cases that they deem the transaction to never be possible to be valid - as an example, if the card no longer exists, and thus there is no point in retrying.

In these cases, the card will be blocked immediately and no further attempts are allowed.

Both of these limitations are based on the combination of the acquiring agreement that the transaction was initiated from, and the PAN of the card that was used. That is, a card might be blocked because of
"Excessive Reattempts" at a particular merchant, while being allowed more reattempts at another. Please note that in the case a new card is issued in place of an old expired one, the new card usually keeps
the same PAN - meaning that if the old card was blocked, the new one will be as well (until the period resets). This marks the importance of having such a logic in place that limits reattempts before the
block actually takes place - this is where the new, clearer response messages will help.


When it comes to Excessive Reattempts, the new response messages will be returned if the quota for the period gets to 5 attempts remaining, as follows:

{
"type": "https://api.payex.com/psp/errordetail/creditcard/suspensionwarning",
"title": "SuspensionWarning. The card might be blocked.",
"status": 403,
"detail": "5 attempts left before the card is blocked.",
"problems": [{
"name": "ExternalResponse",
"description": "Forbidden-AuthenticationRequired"
}, {
"name": "SuspensionWarning",
"description": "5 attempts left before the card is blocked."
}, {
"name": "AUTHENTICATION_REQUIRED",
"description": "Acquirer soft-decline, 3-D Secure authentication required, response-code: O5"
}, {
"name": "Component",
"description": "pospay-ecommerce-financial-service"
}
]
}

Should more attempts be tried, and the transaction fail, the number of remaining attempts will update accordingly.


Once the card is blocked, the following responses will be given, depending on if the card in question is Visa or Mastercard:

Mastercard:
{
"type": "https://api.payex.com/psp/errordetail/creditcard/dailylimitexceeded",
"title": "Daily attempt limit is exceeded.",
"status": 403,
"detail": "The attempt is rejected after trying multiple times with same token.",
"problems": [{
"name": "REJECTED_BY_POSPAY_DAILY_LIMIT",
"description": "Intent with intentId 85ac3576-1e69-4aef-a066-84a0e6dcfa61, agreementId 80d0244c-2b15-4719-8ab1-ed83eddfee61 was suspended after exceeding the rolling 24 hour constraint of 10 attempts"
},
  {
"name": "Component",
"description": "pospay-ecommerce-financial-service"
}
]
}


Visa:
{
"type": "https://api.payex.com/psp/errordetail/creditcard/monthlylimitexceeded",
"title": "Monthly attempt limit is exceeded.",
"status": 403,
"detail": "The attempt is rejected after trying multiple times with same token.",
"problems": [{
"name": "REJECTED_BY_POSPAY_MONTHLY_LIMIT",
"description": "Intent with intentId 80456a1d-1cb1-429b-bf4e-8e1313362800, agreementId 3a47c702-7963-4915-9567-e1bce06d20dd was suspended after exceeding the rolling 30 day constraint of 15 attempts"
},
  {
"name": "Component",
"description": "pospay-ecommerce-financial-service"
}
]
}



The new responses for "Do Not Retry" will be as follows

The card being blocked, and no further attempts are allowed:
{
"type": "https://api.payex.com/psp/errordetail/creditcard/acquirererrordonotretry",
"title": "Do not retry.",
"status": 403,
"detail": "The attempt is rejected.",
"problems": [{
"name": "ExternalResponse",
"description": "Forbidden-AcquirerErrorDoNotRetry"
}, {
"name": "REJECTED_BY_ACQUIRER_DO_NOT_RETRY",
"description": "TOKEN04.ERR_FLG received in response, response-code: 05"
}, {
"name": "Component",
"description": "pospay-ecommerce-financial-service"
}
]
}


Furthermore, a new response is added, being returned in the case where the transaction is declined, but might be accepted after modifications:
{
"type": "https://api.payex.com/psp/errordetail/creditcard/acquirererrormodificationsrequired",
"title": "Modifications required.",
"status": 403,
"detail": "The attempt is rejected. Modifications required.",
"problems": [{
"name": "ExternalResponse",
"description": "Forbidden-AcquirerErrorModificationsRequired"
}, {
"name": "REJECTED_BY_ACQUIRER_MODIFICATIONS_REQUIRED",
"description": "TOKEN04.ERR_FLG received in response, response-code: 05"
}, {
"name": "Component",
"description": "pospay-ecommerce-financial-service"
}
]
}





In addition to the new responses shown above, the following will be added to more clearly show that a specific token is non-existant. These will, as an example, be returned as a response to a request for a previously
deleted token.


{
"type": "https://api.payex.com/psp/errordetail/paymentorders/paymenttokeninactive",
"title": "Payment token is inactive",
"status": 422,
"instance": "https://api.payex.com/psp/probleminstance/00-2fc18bd40743401596bf2de3b51ab16d-bfebd4ae81ea8423-01",
"detail": "The given UnscheduledToken is inactive.",
"problems": [{
"name": "UnscheduledToken",
"description": "The given UnscheduledToken is inactive."
}
]
}




{
"type": "https://api.payex.com/psp/errordetail/paymentorders/paymenttokeninactive",
"title": "Payment token is inactive",
"status": 422,
"instance": "https://api.payex.com/psp/probleminstance/00-2fc18bd40743401596bf2de3b51ab16d-bfebd4ae81ea8423-01",
"detail": "The given RecurrenceToken is inactive.",
"problems": [{
"name": "RecurrenceToken",
"description": "The given RecurrenceToken is inactive."
}
]
}

Feb 14, 16:03 CET
Completed - The scheduled maintenance has been completed.
Feb 21, 10:30 CET
In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary.
Feb 21, 10:00 CET
Scheduled - We will be making a change in the error messages that are given in response in the eCommerce API in the case that the requested Payment/One-Click/Recur/Unscheduled-token does not exist or is deleted.

The following new errorType will be introduced (only for Payment Order):
https://api.payex.com/psp/errordetail/paymenttokeninactive

In addition to the one that is in currently in use (for both Payment Instruments and Payment Order):
https://api.payex.com/psp/errordetail/inputerror

The flow will be as follows:

First, a check is made to verify if the token exists or not. If it does not exist, the API returns an error of the type "InputError". If, however, the token exists but is deleted, then the API returns an error of the type "TokenInactive".

Examples of the error messages are presented below.

InputError, in this instance for RecurrenceToken:
{
"type":"https://api.payex.com/psp/errordetail/inputerror",
"title":"Error in input data",
"status":400,
"instance":"https://api.payex.com/psp/probleminstance/00-e53deef0eb5e47bcb5ba1739bdd9086c-
b5512dfc02b74f07-01",
"detail":"Input validation failed, error description in problems node!",
"problems":
[
{
"name":"RecurrenceToken",
"description":"The given RecurrenceToken does not exist."
}
]
}


TokenInactive, in this instance for UnscheduledToken:
{
"type": "https://api.payex.com/psp/errordetail/paymenttokeninactive",
"title": "Payment token is inactive",
"status": 422,
"instance": "https://api.payex.com/psp/probleminstance/00-2fc18bd40743401596bf2de3b51ab16d-
bfebd4ae81ea8423-01",
"detail": "The given UnscheduledToken is inactive.",
"problems":
[
{
"name": "UnscheduledToken",
"description": "The given UnscheduledToken is inactive."
}
]
}

Do not hesitate to contact us via the ordinary support channels if any questions should arise.

Feb 2, 09:25 CET
Feb 20, 2024
Resolved - This incident has been resolved.
Feb 20, 15:12 CET
Identified - Swish are currently experiencing a service disruption. They are working to restore the service as soon as possible. Thank you for your patience.
Feb 20, 14:43 CET
Feb 19, 2024
Resolved - This incident has been resolved.
Feb 19, 09:37 CET
Investigating - Verifone are currently having issues with clearing files which will cause delays with payouts to some customers. The delayed payouts are expected to be made on Monday 19/2.
Sorry for any inconvenience this may cause.

Feb 16, 09:40 CET
Feb 18, 2024

No incidents reported.

Feb 17, 2024

No incidents reported.

Feb 16, 2024
Resolved - This incident has been resolved.
Feb 16, 09:39 CET
Identified - Verifone are currently having issues with clearing files which will cause delays with payouts to some customers. The delayed payouts are expected to be made tomorrow Friday 16/2.
Sorry for any inconvenience this may cause.

Feb 15, 09:24 CET
Feb 15, 2024
Resolved - This incident has been resolved.
Feb 15, 18:24 CET
Update - We are continuing to work on a fix for this issue.
Feb 15, 17:56 CET
Identified - We are currently experiencing a service degradation. We are working to restore the service as soon as possible. Thank you for your patience
Feb 15, 17:41 CET
Resolved - This incident has been resolved.
Feb 15, 15:22 CET
Identified - Nets are currently having issues with clearing files which will cause delays with payouts to some customers. The delayed payouts are expected to be made tomorrow Thursday 15/2.
Sorry for any inconvenience this may cause.

Feb 14, 09:09 CET
Feb 14, 2024
Completed - The scheduled maintenance has been completed.
Feb 14, 10:30 CET
In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary.
Feb 14, 10:00 CET
Scheduled - We will be making a change in the error messages that are given in response in the eCommerce API in the case that the requested Payment/One-Click/Recur/Unscheduled-token does not exist or is deleted.

The following new errorType will be introduced (only for Payment Order):
https://api.payex.com/psp/errordetail/paymenttokeninactive

In addition to the one that is in currently in use (for both Payment Instruments and Payment Order):
https://api.payex.com/psp/errordetail/inputerror

The flow will be as follows:

First, a check is made to verify if the token exists or not. If it does not exist, the API returns an error of the type "InputError". If, however, the token exists but is deleted, then the API returns an error of the type "TokenInactive".

Examples of the error messages are presented below.

InputError, in this instance for RecurrenceToken:
{
"type":"https://api.payex.com/psp/errordetail/inputerror",
"title":"Error in input data",
"status":400,
"instance":"https://api.payex.com/psp/probleminstance/00-e53deef0eb5e47bcb5ba1739bdd9086c-
b5512dfc02b74f07-01",
"detail":"Input validation failed, error description in problems node!",
"problems":
[
{
"name":"RecurrenceToken",
"description":"The given RecurrenceToken does not exist."
}
]
}


TokenInactive, in this instance for UnscheduledToken:
{
"type": "https://api.payex.com/psp/errordetail/paymenttokeninactive",
"title": "Payment token is inactive",
"status": 422,
"instance": "https://api.payex.com/psp/probleminstance/00-2fc18bd40743401596bf2de3b51ab16d-
bfebd4ae81ea8423-01",
"detail": "The given UnscheduledToken is inactive.",
"problems":
[
{
"name": "UnscheduledToken",
"description": "The given UnscheduledToken is inactive."
}
]
}

Do not hesitate to contact us via the ordinary support channels if any questions should arise.

Feb 2, 09:23 CET
Resolved - This incident has been resolved.
Feb 14, 08:37 CET
Monitoring - A fix has been implemented and we are monitoring the results.
Feb 13, 10:04 CET
Investigating - We are currently experiencing disturbances with our clearing and settlement services. This may be experienced as a delay in payouts to your bank account. We are currently investigating.
Feb 13, 08:57 CET
Feb 13, 2024
Resolved - This incident has been resolved.
Feb 13, 13:04 CET
Identified - Verifone are currently having issues with clearing files which will cause delays with payouts to some customers. Payouts are expected to be made tomorrow Tuesday 13/2.
Sorry for any inconvenience this may cause.

Feb 12, 11:16 CET
Completed - The scheduled maintenance has been completed.
Feb 13, 10:30 CET
In progress - Scheduled maintenance is currently in progress. We will provide updates as necessary.
Feb 13, 10:00 CET
Scheduled - There are more advanced security threats in the digital arena today. Secure start verifies that it's the same person using our services who is identifying themselves with BankID.
This is one of many means to help to prevent fraud. In order to protect both users and e-services, the secure start of BankID becomes mandatory for all authorities, companies and organizations that use BankID in their e-services.
This needs to be implemented by May 1, 2024 at the latest.

The change will be implemented for invoice transactions in the production environment and will thus be affecting all SCA-enabled invoice transactions from now on.

Later in Q1, this will also be implemented for the payment method Installment Account.

There is no need for changes or adjustment from you side for Secure Start (QR-code) for BankID to work - it will all be handled from our side. This release is a re-release of the one done 24/1, where some issues was discovered and a subsequent rollback was done. The issues has now been resolved and a new release will be made.

We do not expect this release to cause any disturbances. If you do notice any sort of problems or unexpected behavior, please contact us via the regular support channels.

Feb 9, 15:02 CET
Feb 12, 2024
Feb 11, 2024
Resolved - This incident has been resolved.
Feb 11, 17:42 CET
Identified - We are currently experiencing a service disruption at third party. Our external provider/supplier is investigating the issue. Thank you for your patience.
Feb 11, 15:46 CET
Feb 10, 2024

No incidents reported.