Klarna's test environment is designed for you to test your integration without incurring actual charges or moving real funds. This simulation allows you to verify that your integration with Klarna's systems functions correctly. Using the test mode is crucial for detecting and resolving potential issues. It should be an integral part of all release procedures to ensure robust testing before deployment to production.

Klarna mandates that all integrators undergo thorough testing in the test environment and provide Klarna comprehensive access to their testing setup for additional validation before going live.

Testing within the live environment is generally discouraged due to the potential for rejections that naturally occur during Klarna validations. However, if testing in the live environment is necessary, be aware of common reasons for rejections:

• Inputting test data (i.e. anything other than your real name, personal email, personal mobile, home billing address, etc)
• Using a company address as personal data
• Insufficient purchase history with Klarna combined with high-value or large quantities of purchases
• Triggering velocity rules - Loading the checkout multiple times in a short space of time from the same device/IP

To minimize complications, focus on extensive testing within Klarna's test environment and limit live tests unless absolutely necessary.

Test your Klarna Partner management API integration by following the test cases below. As a Klarna acquiring partner, we require you to complete and pass all the test cases listed in this section unless exceptions have been approved by Klarna. If a specific product or interaction with Klarna is not included in your integration, and this has been documented in your Solution Scope Document, the representative test case should be skipped.

Steps to follow:

1. Create new API credentials for your own Acquiring partner account.
2. List the credentials to inspect all created API credentials.

Steps to follow:

1. Onboard a new Partner and get the credentials.
2. Validate all the account and business info, store collections, and all the other important details are sent to Klarna.

You can use this sample data found on docs.klarna.com.

Klarna Partners working with Klarna can proactively suspend a product associated with an account if they stop their relationship with that account holder or believe the account may be breaking the terms of their agreement.

Steps to follow:

1. Onboard a new Partner and get the credentials.
2. Suspend a payment product.
3. Revert the suspension.

stores represent how Klarna’s products are shown to the end customers, be it a website, physical store or a mobile app. Using the correct website store ensures that the correct branding and identity features are displayed to customers, enhancing their experience.

store collection information is crucial for enhancing the customer’s purchase and post-purchase experience. In a production environment, the customer will be able to take additional actions such as reaching out to customer support or reviewing return processes for the specific Partner where they have made a purchase. This information is linked to specific stores like websites, apps, or physical stores, ensuring that all transactions made through these stores have access to relevant support information when needed.

It's important that the account information reflects the latest information about your Partners at all times. Fetch and update account information to ensure that all systems are aligned with regards to this information.
This should be programmatically handled whenever an update is applied to an account in your system. Ensure you are testing that the end-to-end functionality is working as expected.

Fetch and update the business information for an account to ensure that the details were correctly sent on onboarding, and that the details can be updated afterwards when required.
This should be programmatically handled whenever an update is applied to an account in your system. Ensure you are testing that the end-to-end functionality is working as expected.

Steps to follow:

1. Fetch the business information for an already existing account.
2. Update any of the details previously fetched for the same account.
3. Verify that the changes are correctly updated in Klarna’s system.

Signing keys are used to verify webhook notifications.

Steps to follow:

1. Create a new signing key.
2. Delete the same signing key.
3. Verify webhooks are working or not, depending on the status of the signing key in use.

Is input sent to Klarna validated, and how are potential errors displayed to the merchant? See the Error handling section for more info of error details and how to handle them.

Test your Klarna integration by following the steps for each of the cases below. Here are some things to keep in mind when you test:

• You can verify the results in the Orders app in the Klarna test portal.
• In all test cases, use Klarna’s sample customer data for the market you are testing.
• Make sure to use your test environment API credentials. Your production keys won't work.
• You can also validate optional data using the Logs app in the Klarna test portal. Keep the API reference open as it will help you to understand the details in the logs.

Steps to follow:

1. Complete a payment transaction with one item: validate your request and the responses received in your backend and check that the product name, price, tax amount, quantity and customer details match the information provided during the customer flow.
2. Process a full capture: simulate shipping the goods to the customer, verify the transaction has been captured in your system and in the Klarna test portal.
3. Process a full refund: simulate returning the transaction by refunding the amount back. Verify the transaction has been refunded in your system and in the Klarna test portal.

Expected outcome:

• The payment confirmation page loads correctly upon transaction completion.
• The payment transaction is created in your system and in the Klarna test portal.
• The payment transaction details in the Klarna test portal and in your system match those entered during the test:
• The payment transaction status updates correctly for both capture and refund stages.

Steps to follow:

1. Complete a payment transaction with at least two items: verify that the cart is being updated when navigating between the checkout and the product pages.
2. Tip: Navigate back and forth between checkout and product pages, and add more than one item to the shopping cart everytime.
3. Process a full capture: simulate shipping the goods to the customer, verify the transaction has been captured in your system and in the Klarna test portal.
4. Process a partial refund: simulate returning just one item and verify that the payment transaction has a status Partially refunded in Klarna test portal, and that the refunded amount and the remaining open amount are correct.

Expected outcome:

• The payment confirmation page loads correctly upon transaction completion.
• The payment transaction details in the Klarna test portal match those entered during the test.
• The payment transaction status updates correctly for both capture and refund stages.

Steps to follow:

1. Complete a payment transaction with at least two items.
2. Process a partial capture: simulate shipping just some of the purchased goods to the customer, verify the transaction has been captured in your system and in the Klarna test portal.
3. Capture the payment in full: simulate shipping the goods to the customer, verify the transaction has been captured in your system and in the Klarna test portal.
4. Process a partial refund: simulate returning just one item and verify that the payment transaction has a status Partially refunded in Klarna test portal, and that the refunded amount and the remaining open amount are correct.
5. Release the remaining amount: verify that the captured amount is correct in your system and in the Klarna test portal, and there’s no remaining open amount for the transaction.

Expected outcome:

• The payment confirmation page loads correctly upon transaction completion.
• Transaction details in the Klarna test portal match those entered during the test.
• Transaction status updates correctly for both capture and refund stages.
• Transaction has no remaining open amount left.

Steps to follow:

1. Complete a payment transaction with at least two items (same as Test case 2) with a discount code.
2. Process a full capture (same as Test case 1): ensure the discount code is taken into account in your system and in the Klarna test portal.
3. Process a full refund (same as Test case 1): ensure the discount code is taken into account in your system and in the Klarna test portal.

Expected outcome:

• The payment confirmation page loads correctly upon transaction completion.
• The payment transaction details in the Klarna test portal match those entered during the test.
• The payment transaction status updates correctly for both capture and refund stages.
• The discount is taken into account in the captured and the refunded amount.

Steps to follow:

1. Complete a payment transaction with at least two items (same as Test case 2) and a gift card to reduce the payment amount.
2. Process a full capture (same as Test case 1): ensure the discount of the gift card t is taken into account in your system and in the Klarna test portal.
3. Process a partial refund (same as Test case 3): ensure the discount of the gift card is taken into account in your system and in the Klarna test portal and the refunded amount and the remaining open amount to be paid are correct.

Expected outcome:

• The payment confirmation page loads correctly upon transaction completion.
• The payment transaction details in the Klarna test portal match those entered during the test.
• The payment transaction status updates correctly for both capture and refund stages.
• The gift card is included in the line items.

Steps to follow:

1. Complete a payment transaction with one item (same as Test case 1)
2. Cancel the payment: verify the cancellation in your system and in the Klarna test portal, check the transaction’s status is Canceled.

Expected outcome:

• The payment confirmation page loads correctly upon transaction completion.
• The payment transaction details in the Klarna test portal match those entered during the test.
• The payment transaction status updates correctly after canceling the transaction.

Steps to follow:

1. Complete a payment transaction with one item (same as Test case 1): use different customer and shipping recipient details.
2. Verify that the transaction has the correct shipping details in your system, and in the Klarna test portal.

Expected outcome:

• The payment confirmation page loads correctly upon transaction completion.
• The payment transaction details in the Klarna test portal match those entered during the test.
• The payment transaction status updates correctly for both capture and refund stages.

Steps to follow:

1. Complete a payment transaction with one item (same as Test case 1): use denied test customer details that result in denied purchase.
2. Confirm the payment flow redirects back to the checkout page, and it allows you to choose another payment method.

Expected outcome:

• The customer can change the payment method after the initial failed payment attempt.

Steps to follow:

1. Initiate a payment transaction where the total payment amount is 0.
2. Proceed through the checkout process as a regular customer.
3. Confirm that the payment flow completes successfully without requiring any payment method.
4. Verify that the payment confirmation page is displayed, indicating a successful transaction.

Expected outcome:

• The customer is able to complete the purchase without any payment method since the total payment amount is 0.
• The payment confirmation page is displayed, confirming the successful completion of the transaction.

Steps to follow:

1. Complete a payment transaction with one item in desktop view (same as Test case 1)
2. Complete a payment transaction with one item in mobile view (same as Test case 1)
3. Complete a payment transaction with one item in mobile app (same as Test case 1)
4. Confirm that any links redirecting to third party apps (e.g. Bank ID and other authentication apps) work.

Expected outcome:

• The payment confirmation page loads correctly upon transaction completion for all devices and views.
• The payment transaction details in the Klarna test portal match those entered during the test.
• The payment transaction status updates correctly for both capture and refund stages.​

Steps to follow:

1. Launch the app and navigate to the login screen.
2. Enter valid login credentials.
3. Enable the “Remember me” checkbox before logging in.
4. Complete the login process.
5. Log out from the app.
6. Close and reopen the app, navigating back to the login screen.

Expected outcome:

• Customer’s login credentials should be pre-filled, indicating the "Remember me" function works correctly within an individual app.
• The customer should be logged in faster if auto-login is supported.

Steps to follow:

1. Log into one app with the “Remember me” option enabled.
2. Close the first app and open a second app integrated with SSO.
3. Navigate to the login screen or a function requiring one's personal details.

Expected outcome:

• The customer’s details are pre-filled when required, validating shared login and remembered login details across different apps using SSO.
• The customer doesn’t need to re-enter the login credentials if the SSO session is active.

Steps to follow:

1. Initiate a payment transaction that requires third-party verification (e.g. BankID in Sweden or similar).
2. Verify that the redirection to an external browser or a third-party app occurs.

Expected outcome:

• The app redirects to the intended external browser or third-party app without errors, ensuring customers can be redirected correctly for authorization within the purchase flow.

Steps to follow:

1. Initiate a transaction that requires redirecting to a US bank's web page known to enforce secure web limitations.
2. Observe the method by which the Mobile SDK handles this redirect.

Expected outcome:

• Mobile SDK renders the bank's page in a secure web window successfully, without using in-app webviews, addressing the secure web limitations imposed by US banks.

Steps to follow:

1. Initiate a transaction that requires redirecting to a US bank's web page known to enforce secure web limitations.
2. Observe the method by which the Mobile SDK handles this redirect.

Expected outcome:

• Mobile SDK, renders the bank's page in a secure web window successfully without using in-app webviews, addressing the secure web limitations imposed by US banks.

Steps to follow:

1. During the payment transaction, initiate the KYC flow.
2. Allow camera access and follow instructions to scan an ID document.
3. Submit the ID document for verification.

Expected outcome:

• The app effectively scans the ID with the camera and completes the verification process, confirming the customer's identity.

Steps to follow:

1. Initiate a payment transaction using a credit card requiring 3DS verification.
2. Verify that the redirect to the bank's 3DS page is successful.
3. Complete the 3DS verification process.

Expected outcome:

• The payment transaction pauses for 3DS verification and upon successful verification, the transaction continues and completes successfully, ensuring the 3DS verification process for card payments functions correctly.

Steps to follow:

1. Initiate a payment transaction with Klarna app installed.
2. Verify that the handover to the Klarna app occurs automatically.
3. Complete necessary authentication or consent in the Klarna app.
4. Check for a redirect back to the original app after completion.

Expected outcome:

• The Klarna app opens without issue, presenting the required authentication or consent screens, followed by a redirect back to the original app to continue or complete the transaction, indicating a seamless app handover for authentication and consent within the Klarna app.

Steps to follow:

1. Create a payment request with additional tokenization parameters
2. Complete the payment request
3. Once the payment request is confirmed using the payment confirmation token, retrieve the customer token from the response body.

Expected outcome:

• Klarna is presented as a payment method for the subscription.
• A customer token is successfully created and stored, and can be used for future charges.

Steps to follow:

1. Create a customer token with the “Customer Not Present on Payment” scope.
2. Charge a tokenized customer for a subscription payment.

Expected outcome:

• The customer is charged with the correct amount.
• The subscription and line item details are included in the token charge call.

Steps to follow:

1. Create a customer token with the “Customer Present on Payment” scope.
2. Login to the partner system as the customer and initiate a transaction
3. Handle step-up authentication flow. Forward the customer to the returned distribution URL and confirm the payment request when the customer has completed the Klarna Payment flow.

Expected outcome:

• The customer is authenticated with a customer account, and can complete transactions without further customer interaction, enabling one-click payments and faster checkouts.
• The customer is redirected to step-up authentication flow when necessary.
• The correct amount, subscription and line item details are included in the token charge call.

Steps to follow:

1. Combine baskets that include both an untokenized transaction and setting up tokenization for recurrent transactions for later payments.
2. Complete the payment request
3. Once the payment request is confirmed using the payment confirmation token, retrieve the customer token from the response body.

Expected outcome:

• The initial one-time purchase is processed, and subsequent subscription charges are successfully made using the customer token.
• The correct amount, subscription and line item details are included in the token charge call.