| StatusCode | -ErrorCodes | -Description | -
| 400 | -1099 1151 1152 1153 1155 1156 1157 1159 1160 1161 1182 |
- Unknown BadRequest error Missing x-mobilepay-merchant-vat-number header Missing x-mobilepay-client-system-name header Missing x-mobilepay-client-system-version header Duplicated x-mobilepay-merchant-vat-number header Duplicated x-mobilepay-client-system-name header Duplicated x-mobilepay-client-system-version header Invalid x-mobilepay-merchant-vat-number header Invalid x-mobilepay-client-system-name header Invalid x-mobilepay-client-system-version header Invalid merchant_vat claim in access token |
-
| 401 | -- | -Unauthorized | -
| 500 | -2000 - 2999 | -Internal server error - Please attach error code when communicating with MobilePay for quicker support | -
| StatusCode | -ErrorCodes | -Description | -
| 403 | -1401 1411 |
- Cannot query payments created by a different integrator Cannot query payments created on behalf of a different merchant |
-
| 404 | -- | -Payment not found | -
| StatusCode | -ErrorCodes | -Description | -
| 400 | -1109 | -Payment filter not specific enough | -
| StatusCode | -ErrorCodes | -Description | -
| 400 | -1102 1113 1117 1162 1163 1164 |
- Invalid Amount Invalid OrderId Invalid MerchantPaymentLabel Invalid x-mobilepay-idempotency-key header Duplicated x-mobilepay-idempotency-key header Missing x-mobilepay-idempotency-key header |
-
| 403 | -1400 | -Cannot initiate payments on a point of sale created by a different integrator | -
| 409 | -1000 1204 1301 1306 |
- Point of Sale not found The store for the given point of sale is not activated. Please activate the store before starting a payment A payment is already active. Cancel it before starting a new one x-mobilepay-idempotency-key header has to be unique per request unless the request is a retry of a previous request |
-
| StatusCode | -ErrorCodes | -Description | -
| 400 | -1113 1162 1163 1164 |
- Invalid OrderId Invalid x-mobilepay-idempotency-key header Duplicated x-mobilepay-idempotency-key header Missing x-mobilepay-idempotency-key header |
-
| 403 | -1400 | -Cannot prepare payments on a point of sale created by a different integrator | -
| 409 | -1000 1204 1301 1306 |
- Point of sale not found The store for the given point of sale is not activated. Please activate the store before starting a payment A payment is already active. Cancel it before starting a new one x-mobilepay-idempotency-key header has to be unique per request unless the request is a retry of a previous request |
-
| StatusCode | -ErrorCodes | -Description | -
| 400 | -1102 1117 |
- Invalid Amount Invalid MerchantPaymentLabel |
-
| 403 | -1401 1406 |
- Cannot ready payments prepared by a different integrator Cannot ready payments prepared on behalf of a different merchant |
-
| 404 | -- | -Payment not found | -
| 409 | -1303 | -Payment needs to be prepared before it can be marked as ready | -
| StatusCode | -ErrorCodes | -Description | -
| 400 | -1102 | -Invalid Amount | -
| 403 | -1401 1407 |
- Cannot capture payments created by a different integrator Cannot capture payments created on behalf of a different merchant |
-
| 404 | -- | -Payment not found | -
| 409 | -1304 1305 1307 1308 |
- Cannot capture payment when payment is not reserved Capture Amount cannot exceed the reserved amount Payment has already been captured with a different amount Partial capture not possible on this payment |
-
| StatusCode | -ErrorCodes | -Description | -
| 403 | -1401 1408 |
- Cannot cancel payments created by a different integrator Cannot cancel payments created on behalf of a different merchant |
-
| 404 | -- | -Payment not found | -
| 409 | -1300 | -The payment cannot be cancelled in the current state | -
| StatusCode | -ErrorCodes | -Description | -
| 403 | -1400 1410 |
- Cannot query point of sales created by a different integrator Cannot query point of sales created on behalf of a different merchant |
-
| 404 | -- | -Point of sale not found | -
| StatusCode | -ErrorCodes | -Description | -
| 400 | -1121 | -Point of sale filter not specific enough | -
| StatusCode | -ErrorCodes | -Description | -
| 403 | -1400 | -Cannot query checkin on a point of sale created by a different integrator | -
| 404 | -- | -Point of sale not found | -
| StatusCode | -ErrorCodes | -Description | -
| 400 | -1100 1111 1112 1116 1118 1162 1163 1164 |
- Invalid BeaconId Invalid MerchantPosId Invalid PosName Invalid CallbackAlias Invalid CalibrationType Invalid x-mobilepay-idempotency-key header Duplicated x-mobilepay-idempotency-key header Missing x-mobilepay-idempotency-key header |
-
| 403 | -1403 | -Cannot create point of sale on store that does not belong to the merchant | -
| 409 | -1002 1200 1202 1306 |
- Store not found A point of sale with that MerchantPosId already exist A point of sale with that BeaconId already exist x-mobilepay-idempotency-key header has to be unique per request unless the request is a retry of a previous request |
-
| StatusCode | -ErrorCodes | -Description | -
| 403 | -1400 1409 |
- Cannot delete point of sales created by a different integrator Cannot delete point of sales created on behalf of a different merchant |
-
| 404 | -- | -Point of sale not found | -
| StatusCode | -ErrorCodes | -Description | -
| 403 | -1402 | -Cannot query refunds created by a different integrator | -
| 404 | -- | -Refund not found | -
| StatusCode | -ErrorCodes | -Description | -
| 400 | -1110 | -Refund filter not specific enough | -
| StatusCode | -ErrorCodes | -Description | -
| 400 | -1102 1114 1162 1163 1164 |
- Invalid Amount Invalid RefundOrderId Invalid x-mobilepay-idempotency-key header Duplicated x-mobilepay-idempotency-key header Missing x-mobilepay-idempotency-key header |
-
| 403 | -1401 | -Cannot refund payments created by a different integrator | -
| 409 | -1001 1306 1354 1365 1366 1367 1368 |
- Payment not found x-mobilepay-idempotency-key header has to be unique per request unless the request is a retry of a previous request Refund of payment not possible when payment is not captured Refund CurrencyCode is different than payment CurrencyCode Payment is too old Refund Amount is too high Cannot refund Amount as it exceeds the available balance on the store |
-
| StatusCode | -ErrorCodes | -Description | -
| 403 | -1402 | -Cannot capture refunds created by a different integrator | -
| 404 | -1004 | -Refund not found | -
| 409 | -1351 | -Cannot capture refund when refund is not reserved | -
| StatusCode | -ErrorCodes | -Description | -
| 403 | -1402 | -Cannot cancel refunds created by a different integrator | -
| 404 | -- | -Refund not found | -
| 409 | -1352 | -The refund cannot be cancelled in the current state | -
| StatusCode | -ErrorCodes | -Description | -
| 404 | -- | -Store not found | -
| StatusCode | -ErrorCodes | -Description | -
| 400 | -1122 1119 1120 |
- Store filter not specific enough Invalid MerchantBrandId Invalid MerchantLocationId |
-
| - | - | - |
| - | - | - |
.default})
](/img/pos-MobilepayButton.png)
-
-A last example of a user activation is in the case of a QR code being displayed in a terminal. Once the QR code is displayed,
-the terminal may start polling the endpoint `GET /v10/pointofsales/{posId}/checkin` to determine if a customer has checked in. The terminal may only poll for a check-in while the QR code is displayed on the terminal to ensure the check-in endpoint is not overloaded with requests.
-
-[.default})
](/img/pos-polling.png)
-
-## Notification service
-
-Some interfaces do not include a possibility for user activation. In these cases an endpoint can be exposed by the MobilePay PoS integrator. This endpoint will be called with a check-in notification when a customer checks in. After receiving a notification the client can poll the `GET /v10/pointofsales/{posId}/checkin` endpoint for that PoS. For more details see [Notification Service](/docs/pos/notification-service).
-
-[.default}){kind=tracking}
](/img/pos-BeaconIDRead.png)
diff --git a/docs/pos/development-guide/_category_.json b/docs/pos/development-guide/_category_.json
deleted file mode 100644
index 7d1a58a2b..000000000
--- a/docs/pos/development-guide/_category_.json
+++ /dev/null
@@ -1 +0,0 @@
-{ "label": "Development Guide", "position": 1 }
diff --git a/docs/pos/development-guide/development-guide.md b/docs/pos/development-guide/development-guide.md
deleted file mode 100644
index f395b2f54..000000000
--- a/docs/pos/development-guide/development-guide.md
+++ /dev/null
@@ -1,5 +0,0 @@
-import DocCardList from '@theme/DocCardList';
-
-# Development Guide
-
-.default})
-
-* Logo: Is highly important as this is the most recognisable by the user. The logo is used for all stores under this the brand. This is uploaded by the merchant in our self-service portal
-* Merchant brand name: This is the name of the brand used when creating the store. The brand name is shown for all stores using this brand. It is set by the merchant in our self-service portal
-* Store: This is the name of the store. The name is only used on this specific store. It is set by the merchant in our self-service portal
-* PoS name: This is the name of the specific PoS set when integrator created the posId through the API: POST /v10/pointofsales - "name"
-
-Self-service portal: [DK](https://admin.mobilepay.dk/) | [FI](https://admin.mobilepay.fi/)
-
-## Design guidelines
-
-We want to make it easy for you to ensure that the right MobilePay buttons and logo's are used by the merchants. Proper use of our logo and buttons will ensure better user experience and conversion rate.
-Please visit our [Design page](https://developer.mobilepay.dk/design) for more information and ressources.
-
-We also have guidelines and templates for signs and stickers which can be found [here](https://www.mobilepay.dk/materialebank/marketingmateriale/skilte/skiltning-til-pos).
diff --git a/docs/pos/development-guide/test.mdx b/docs/pos/development-guide/test.mdx
deleted file mode 100644
index 3bcdefe85..000000000
--- a/docs/pos/development-guide/test.mdx
+++ /dev/null
@@ -1,99 +0,0 @@
----
-sidebar_position: 2
----
-
-import Tabs from "@theme/Tabs"
-import TabItem from "@theme/TabItem"
-import TestApp from '/docs/shared-blocks/_test-app.mdx';
-
-# Test
-
-In this section, you can find information on testing, and our test ressources. To ensure a good user experience, we recommend you to test your solution thoroughly before certification and launch.
-
-## MobilePay PoS Sandbox Environment
-
-We have provisioned a sandbox environment for integration purposes The environment is the same bits and bytes as the production environment, with a few exceptions:
-
-* No actual payments and reservations are made. The payment backend have been mocked, and the transactions are kept in sandbox storage. This means that transactions won’t be visible in the test app activity list, and no app notifications are sent.
-* Loyalty card system is also mocked, and static loyalty card information is returned when applicable
-
-**Audience**: The test environment is meant for PoS integrators to be able to test integrations against the MobilePay PoS platform. It is an isolated environment that behaves as in live production, thus enabling PoS integrators to fully test the PoS API and business logic.
-
-**Background**: The environment is strictly meant for carrying out tests and development tasks towards certification.
-
-**The API**: The Merchant API in the sandprod environment is identical to the live production API.
-
-To complete a payment flow in the sandprod environment you will need to make user actions. To do so you have to options:
-
-* User simulation API: The API mimick the actions of a user and allows you to check in on a beaconId, accept and cancel a payment.
-* Test app: This version of the MobilePay app is similar to the live version, but only supports payments in the sandprod environment.
-
-## Test app
-
-.default})
-
-When the customer cancels the payment the app will show a message saying that the payment was cancelled. The status of the payment when queried will be *CancelledByUser*.
-
-.default})
-
-The cancel funtionality can be used in various scenarios. It could be that the customer changed their mind about paying with MobilePay or that something in the request was not correct (maybe the customer added another item after the payment was initiated). In these cases the cancelling of the payment is straight forward and as shown in the diagrams above.
-
-The cancel functionality can also be used in case of non-sunshine scenarios.
-It could be if the call to initiate a payment is faulty or if the client never receives the response. In this case the client should either retry the call (as described in [Error Handling](/docs/pos/api-principles#error-handling)) or the client could try to get the `paymentId` by the `orderId` and cancel afterwards.
-
-## Cancelling Refunds
-
-A client can end up in situations, where the status of a refund is not known e.g. in cases, where parts of the solution is down, or there are network issues. In these cases, it is important, that the client retains information about refunds, that have been requested. It is then possible for the client to follow up on whether the refund should be cancelled or captured. Examples for either cancel or capture could be: In the case of cancel - the customer has received refund in cash instead. In the case of capture - the customer has left the store with information that the payment will be refunded.
-
-A refund is cancellable until it reaches one of the states *CancelledByMobilePay*, *Captured* or *ExpiredAndCapturred*. Refunds can only be cancelled by the client since there is no customer involved in the process. A refund can be cancelled by calling the endpoint `POST /v10/refunds/{refundId}/cancel`. It requires the id of the refund that was returned when the refund was initiated.
-When the refund has been cancelled the state transitions to *CancelledByClient*.
-
-.default})
\ No newline at end of file
diff --git a/docs/pos/payment-flows/partial-capture.md b/docs/pos/payment-flows/partial-capture.md
deleted file mode 100644
index 41eb6554a..000000000
--- a/docs/pos/payment-flows/partial-capture.md
+++ /dev/null
@@ -1,24 +0,0 @@
----
-sidebar_position: 6
----
-
-# Partial Capture
-
-It is possible for all merchants to capture partial amounts in the API. MobilePay do however have to comply with card scheme rules which means that when a payment is done using an underlying card, some payments will not be possible to partially capture. To solve this every payment in *Reserved* state will contain information about whether or not it is possible to capture a partial amount on the payment. The information is presented in a flag `PartialCapturePossible` that will be set to either `true` or `false`.
-Based on the value of this flag, a mechant/integrator must choose to proceed with or cancel the payment before delivering the goods to the customer.
-
-Here is the flow where partial capture is possible.
-
-.default})
-
-Here is the flow where partial capture is not possible and hence the payment needs to be cancelled.
-
-.default})
\ No newline at end of file
diff --git a/docs/pos/payment-flows/payment-flow-error-handling.md b/docs/pos/payment-flows/payment-flow-error-handling.md
deleted file mode 100644
index 7b2fb301d..000000000
--- a/docs/pos/payment-flows/payment-flow-error-handling.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-sidebar_position: 3
----
-
-# Payment Flow Error Handling
-
-Of all the ways a payment flow can fail, there are some error scenarios related to initiating payment flows that the client needs to focus on. The following sections describes how to handle payment-in-progress errors and how to handle payments hanging in the *Reserved* state.
-
-## Payment in progress error handling
-
-In the case of an unexpected restart of the client where the payment flow cannot be continued it might be necessary to cancel the active payment since there can be only one active payment on a PoS. If the ``paymentId`` of the active payment is lost it can be retrieved by calling ``GET /v10/payments`` using the ``posId`` and `orderId`. When the `paymentId` is retrieved the payment can be cancelled and the PoS is now ready for a new payment flow. A sequence diagram showing how to handle a payment-in-progress error is shown below.
-
-.default})
-
-## Hanging payments in reserved state
-
-The client is responsible for persisting if a reserved payment should be cancelled or captured. In case the client gets a timeout (or other errors resulting in failed calls) trying to either call capture or cancel on a payment, it is crucial that they persist whether the payment should be captured or cancelled so they can try again later.
-
-It is required of the client to implement a periodically scheduled job of running through all their payments left in *Reserved* state, and try to either cancel or capture it. A sequence diagram of this flow is shown below. It is the responsibility of the client to keep track of the payments left in *Reserved* state.
-
-.default})
diff --git a/docs/pos/payment-flows/payment-flow.md b/docs/pos/payment-flows/payment-flow.md
deleted file mode 100644
index 9f39d63e0..000000000
--- a/docs/pos/payment-flows/payment-flow.md
+++ /dev/null
@@ -1,27 +0,0 @@
----
-sidebar_position: 1
----
-
-# Payment Flow
-
-The payment flow makes the payment ready for customer approval immediately upon creation. The sequence diagram below illustrates a sunshine scenario for a payment flow.
-
-The customer checks in on the PoS and receives information about the store on his device. Then, the client initiates a payment on the PoS which is immediately ready for approval and issued to the customer. The payment is now in the *IssuedToUser* state and will remain there until the customer accepts the payment and the payment amount has been reserved. At that point the payment will transition to the *Reserved* state. In this state, the payment can be cancelled or captured by the client resulting in the payment state transitioning to either the *Cancelled* or *Captured* state, respectively.
-
-[](/img/pos-PaymentFlow-PaymentAfterCheckIn.png)
-
-It is also possible to initiate a payment on a PoS without an active check-in, as shown in the sequence diagram below. In this case the payment state starts out as *Initiated* and remains in that state until a customer is paired with the payment through a check-in. At that point the payment request is immediately issued to the customer and the state of the payment transitions to *IssuedToUser*. The rest of the flow proceeds in the same way as the scenario above.
-
-[](/img/pos-PaymentFlow-PaymentBeforeCheckIn.png)
-
-## Payment States for the Payment Flow
-
-The diagram below shows all the possible states and transitions for a Payment flow. A payment can be cancelled by the customer until the customer has accepted the payment and the payment amount has been reserved. A payment can be cancelled by the client until it is captured or expires. After a payment has been captured, it can be [refunded](#refunds), but can no longer be cancelled. A payment expires if it is neither cancelled nor captured within the lifetime of the reservation which is 7 days. If a payment expires, the state transitions to *ExpiredAndCancelled*.
-A payment in the *Initiated* or *IssuedToUser* state can also be cancelled by MobilePay if it has been inactive for too long or an error occurs while reserving the payment amount on the customer's card or account. If a payment is
-cancelled by MobilePay the state transitions to *CancelledByMobilePay*. The Payment states *Initiated* and *IssuedToUser* are called *active* states and will block further payments on the same Point-of-Sale.
-
-.default})
diff --git a/docs/pos/payment-flows/payment-flows.md b/docs/pos/payment-flows/payment-flows.md
deleted file mode 100644
index 0183b6756..000000000
--- a/docs/pos/payment-flows/payment-flows.md
+++ /dev/null
@@ -1,10 +0,0 @@
-# Payment overview
-
-The MobilePay PoS API exposes two separate flows for payments which are documented in this section:
-
-* [Payment flow](/docs/pos/payment-flows/payment-flow)
-* [Prepared payment flow](/docs/pos/payment-flows/prepared-payment-flow)
-
-All payments must be explicitly captured by the client after the customer has approved the payment. The capture amount can be for the full or a partial amount (if allowed on the payment).
-
-For a client to start a payment flow, the client first has to detect that a customer is present, ready and willing to pay. In the following descriptions of payment flows it is assumed that the client has already detected a customer. How to detect a customer wanting to pay with MobilePay is described in the [Detecting MobilePay](/docs/pos/detecting-mobilepay) section.
diff --git a/docs/pos/payment-flows/prepared-payment-flow.md b/docs/pos/payment-flows/prepared-payment-flow.md
deleted file mode 100644
index 8a53f7a1b..000000000
--- a/docs/pos/payment-flows/prepared-payment-flow.md
+++ /dev/null
@@ -1,25 +0,0 @@
----
-sidebar_position: 2
----
-
-# Prepared Payment Flow
-
-The prepared payment flow makes the payment accessible to the customer on creation, pending an amount. Only when the payment is readied will the customer be able to make the approval.
-
-As an example, this flow could be used to start a payment before the payment amount is known. This could for instance be because goods are still being scanned at a cash register or to support loyalty flows.
-
-The sequence diagram below illustrates a sunshine scenario for a prepared payment flow.
-
-A prepared payment starts out in state *Prepared* and remains in this state until the payment is paired with a customer through a check-in. Once paired, the state transitions to *Paired*. Subsequently, polling of the payment can be done to retrieve a potential loyalty token. Once the payment is ready for customer approval, the client marks the payment as *Ready* and provides the payment amount. The payment is then issued to the customer and the payment state changes to *IssuedToUser*. Once the customer accepts the payment request and the payment amount has been reserved, the payment state transitions to the *Reserved* state. In this state, the payment can be cancelled or captured by the client resulting in the payment state transitioning to either the *CancelledByClient* or *Captured* state, respectively.
-
-[](/img/pos-ReservationPrepareFlow.png)
-
-## Payment States for the Prepared Payment Flow
-
-The diagram below shows all the possible states and transitions for a prepared payment flow. The "Prepared Payment Flow" state diagram expands upon the ["Payment Flow" state diagram](/docs/pos/payment-flows#payment-states-for-the-payment-flow) by adding two additional states, *Prepared* and *Paired*. The client and MobilePay can cancel a prepared payment. The customer can cancel a paired payment. The Payment states *Initiated*, *Prepared*, *Paired* and *IssuedToUser* are called *active* states and will block further payments on the same Point-of-Sale.
-
-[.default})
](/img/pos-prepared-payment-states.png)
diff --git a/docs/pos/payment-flows/refunds.md b/docs/pos/payment-flows/refunds.md
deleted file mode 100644
index ac61501e0..000000000
--- a/docs/pos/payment-flows/refunds.md
+++ /dev/null
@@ -1,28 +0,0 @@
----
-sidebar_position: 4
----
-
-# Refunds
-
-Once a payment is captured, the payment amount is immediately charged from the customer. Therefore, the payment can no longer be cancelled. Instead, the payment amount can be transferred back to the customer, by performing *refunds*. Each captured payment can be refunded multiple times with the restriction that the sum of the refunds cannot exceed the captured payment amount. A payment can be refunded up to 90 days after the payment was captured. After 90 days a refund is no longer possible with MobilePay.
-
-A refund can be executed if the store payment balance contains enough money to cover the refund. If the balance doesn’t cover the amount of the refund, the refund will fail with error code 1368
-
-The sequence diagram below shows a sunshine scenario for a refund. Initiating a refund yields a `refundId` that can be used to capture the refund. A refund starts out in the *Initiated* state and transitions to the *Reserved* state when the refund has been reserved as shown in the state diagram below. Once a refund has been reserved, the client can choose to capture the refund, transitioning the state to *Captured*. When a refund is captured, the refunded amount is immediately transferred to the customer and the customer will be able to see the refund in the activity list.
-A refund reservation will expire and be automatically captured after 24 hours.
-
-.default})
-
-Until the refund has been captured, the client can also choose to cancel the refund. The diagram below shows the possible states and transitions for a refund.
-
-.default})
-
-To refund a payment, the client needs to provide the paymentId of the payment to be refunded. In case the paymentId has been lost it can be retrieved by calling `GET /v10/payments?orderId={orderId}&state=Captured` with the orderId from the payment to be refunded.
diff --git a/docs/pos/pos-management.md b/docs/pos/pos-management.md
deleted file mode 100644
index d62440380..000000000
--- a/docs/pos/pos-management.md
+++ /dev/null
@@ -1,125 +0,0 @@
----
-sidebar_position: 5
----
-
-# Point-of-Sale Management
-
-The Point-of-Sale (PoS) represents the contact point between a customer wanting to pay with MobilePay and the merchant.
-To initiate a MobilePay payment it is necessary to first create a PoS.
-
-## Onboarding
-
-Each PoS belongs to a *Store* which belongs to a *Brand*. A brand can be thought of as a combination of a name and a logo. An example of a brand could be 7-Eleven in Denmark or K-Market in Finland. Each brand consists of one or more stores. A store is the representation of a merchant's shop. It contains a `storeId` as well as the name and the address of the shop. When a MobilePay customer checks in on a PoS they will see the brand logo and name as well as the shop name in the app, which helps the customer confirm that they have in fact checked in where they intended.
-When an integrator needs to onboard a PoS they need the `storeId` to create all the PoSes on that store. The `storeId` will therefore have to be persisted in an application configuration file for subsequent calls to the V10 API. There are generally two ways to acquire the `storeId`. The recommended option depends on the merchant being a migrated merchant or not. The two different approaches are described below.
-
-### No existing solution
-
-When an integrator is building a new integration for a merchant they need to know the store to which the PoS should be created. The goal is to get a list of all the stores that belongs to a merchant and then use the `storeId` from the appropriate store to create the PoS. First the integrator needs to call `GET /v10/stores` without any query parameters and the endpoint will return all the `storeId`s based on the Merchant VAT either provided in the `x-mobilepay-merchant-vat-number` header or provided in the access token (see [Authentication](/docs/pos/authentication#obtaining-an-access-token)). Then the integrator will loop through the list and for each `storeId` call `GET /v10/stores/{storeid}` that will return the store information for that specific store. In the end the integrator have a list of all the stores the merchant has and then the integrator knows which ``storeId`` for each store to use when creating a PoS. Below diagram illustrates a flow to get all merchant stores.
-
-.default})
-
-### Existing solution
-
-A brand is identified by a `merchantBrandId`. A `merchantLocationId` together with a `merchantBrandId` identifies a store within a brand.
-If the merchant already has a MobilePay PoS solution with integration to either API V06, V07 or V08 then an integrator can use the already known `merchantBrandId` and `merchantLocationId` to get the `StoreId`, If the `merchantBrandId` and ``merchantLocationId`` is not known the process from the above paragraph will be the most efficient. To get the `StoreId` the integrator will have to call `GET /v10/stores` with the two ids, and in return they will receive the `storeId`. Below diagram illustrates a flow for getting the ``storeId`` using `GET /v10/stores`.
-
-.default})
-
-## PoS Creation
-
-A PoS is created using the `POST /v10/pointofsales` endpoint. A PoS is identified in the PoS V10 API by a `posId` that is assigned by MobilePay upon creation of the PoS. Clients can provide their own internal identifier as a `merchantPosId` upon creation and use the `GET /v10/pointofsales` endpoint to lookup a `posId` based on a `merchantPosId`. The `merchantPosId` field is required, so if no internal identifier is applicable, the client should generate and supply a random string (eg. a fresh GUID) instead.
-
-### Beacons
-
-The first thing to consider when creating a PoS is what beacon(s) will be used to connect MobilePay users to the given PoS.
-This can range from an unmanned vending machine that has no payment hardware at all and hence only shows a QR code on a screen, to a full fledged super market ECR with a 2-way bluetooth capable terminal that also can show a QR code. To create a PoS, the client needs to provide a list of possible ways to detect the PoS. The more accurate the list is, the better MobilePay will be able to detect errors (if bluetooth is provided as a beacon type but we detect that no user ever checks in via bluetooth something is likely wrong). It is recommended to keep the list of supported beacon types in an application configuration and then edit the list in case the setup changes.
-
-Each beacon, whether through a MobilePay QR code or a bluetooth/NFC signal, encodes a `beaconId` that can be read by the MobilePay app. It is the `beaconId` that is used to connect a MobilePay user to a specific PoS. `beaconId`s are globally unique across all merchants in MobilePay PoS and each `beaconId` can refer to at most one active PoS at any given time.
-
-Depending on the client setup, there are different use cases for handling `beaconId`s in API V10
-
-#### Client that only supports dynamic QR codes
-
-In case the client only allows QR beacons (no physical device) and can create a QR code dynamically (i.e generate a QR code and show it on a screen in opposition to printing a physical QR code), then the client can choose to let MobilePay create a GUID to use as `beaconId`. The client then omits to provide a `beaconId` on PoS creation and afterwards queries the PoS to get the `beaconId`. The client can then store the `beaconId` in memory for QR code generation. Everytime the client reboots the client then has to query the PoS and grab the `beaconId`. This way the client is not required to store a `beaconId` in a configuration file since they can rely on querying it dynamically.
-
-#### Client that only supports static QR codes
-
-In case the client only allows QR beacons but is not able to generate a QR code dynamically, the client needs the ````beaconId```` for the PoS creation. The following options are available:
-
-1. The client can generate the `beaconId` and provide it on PoS creation
-2. An arbitrary `beaconId` can be produced outside the client and be inputted to the client for instance using readers, scanners or inputted using a keyboard. MobilePay can generate the `beaconId` automatically as part of the production of stickers, if stickers are needed as the “acceptance device”.
-
-If stickers are needed as the acceptance device, we suggest that you use MobilePay to help deliver QR-code stickers to your merchants using option 2.
-
-:::note
-The easiest way of handling stickers is if the client is set up to support activation and deactivation of QR codes directly from the merchant location.
-You can order the stickers directly from MobilePay’s print supplier’s sticker webshop, and the Beacon IDs and QR codes will automatically be generated. The BeaconId will be printed on the sticker, so that it can be added by the merchant, or the merchant can report to you, which Beacon IDs the merchant uses.
-[Sticker Webshop](https://mp.bordingcentral.dk)
-:::
-
-The `beaconId` should then be stored locally in a configuration file so that it can be used if the PoS needs to be updated (i.e. deleted and re-created. See [PoS Update and Deletion](/docs/pos/pos-management#pos-updating-and-deletion)). To avoid clashes, the client must use a GUID as the `beaconId`.
-
-#### Client that supports physical devices (terminals, MobilePay white boxes)
-
-In cases where the client uses a physical device then that device will have a MobilePay `beaconId` associated with it. On PoS creation this `beaconId` has to be provided. Some devices allows a client to read the `beaconId` from it. If that is the case we recommend to read the `beaconId` when the client reboots and query the PoS to see if the `beaconId`s match. If not delete the PoS and re-create it with the new `beaconId`. This will make it possible to replace the device if its broken, and only have to reboot the system to propagate the changes.
-If reading the `beaconId` from the device is not possible, we recommend to store the `beaconId` locally in a configuration file so that it persists through reboots.
-
-### Preventing checkin before payment
-
-Normally, a user is allowed to check in on a point of sale before a payment is created. Then, once the payment is created, the payment will pop up on the user's phone for them to pay. However, in some cases, this is not what you want.
-
-For example, in a self-service solution, a user could check in on a point of sale, walk away, and then they'll get paired to the next user's payment if the next user does not take over the check-in in time.
-
-When creating a PoS, the client can set the `requirePaymentBeforeCheckin` property to `true` (by default it is `false`), and then users are not allowed to check in to a point of sale before a payment is created on the point of sale. This ensures that no users are checked in when the payment is created, so you can ensure the correct user gets paired.
-
-### Callback
-
-If the client system cannot detect when a MobilePay user wants to pay and therefore needs to use the [Notification service](/docs/pos/detecting-mobilepay#notification-service), the client should set the callback parameter accordingly when calling `POST /v10/pointofsales`.
-It is recommended to store the callback alias in the config file of the application.
-
-### Naming
-
-The last thing to keep in mind when creating a PoS is to consider the name. When a MobilePay user checks in on the PoS they will in the app see, in sequence: The name of the brand, the name of the store and the name of the PoS. We recommend naming the PoS so that the MobilePay user can verify that they in fact have checked in the right place. So in a supermarket scenario a good name for the PoS would be "Check-out 1" for the first check-out counter in that supermarket.
-
-## PoS Updating and Deletion
-
-A PoS can be deleted using the `DELETE /v10/pointofsales/{posId}` endpoint.
-
-We recommend only deleting a PoS if it is either not going to be used anymore, or you need to update it to reflect changes like a new callback alias, new name, new `beaconId` etc.
-
-When a PoS is deleted it is no longer possible to issue payments. However it will still be possible to capture or cancel payments that are in the reserved state. It is best practice to delay the deletion of a PoS until all payments have either been cancelled or captured.
-
-## Keeping in sync with MobilePay
-
-### When PoS reboots
-
-When the client reboots it is good practice to query the PoS with `GET /v10/pointofsales` with the `merchantPosId` and persist the `posId` in memory to use for initiating payments. If no PoS is returned, the client will have to re-create it. Here is the flow described:
-
-.default})
-
-We recommend the client to store the following in a configuration file to be able to create the PoS when needed:
-
-* `StoreId`
-* `MerchantPosId`
-* Name of PoS
-* `BeaconId` (unless it can be read from the device itself. See [Beacons](/docs/pos/pos-management#beacons) )
-* Callback (If the client is dependent on the notification service. See [Callback](/docs/pos/pos-management#callback))
-* Supported beacon types
-
-## Master Data
-
-A PoS belongs to a store which in turn belongs to a merchant and associated with a brand. A PoS is identified by a `posId`, but it is also possible to refer to a PoS by its `beaconId` or `merchantPosId`. There can be at most one active PoS with a given `beaconId` at any given time. There can be at most one active PoS with a given `merchantPosId` at any given time, for a given integrator and merchant.
-
-A store is identified by a `storeId`, but it is also possible to refer to a store by the combination of `merchantBrandId` and `merchantLocationId`. Two stores with the same `merchantLocationId` but different `merchantBrandId`s are not related in any way. The `merchantBrandId`, `merchantLocationId` and `storeId` are supplied by MobilePay when the Merchant/Store is onboarded.
diff --git a/docs/pos/pos.md b/docs/pos/pos.md
deleted file mode 100644
index 1cc4c1c54..000000000
--- a/docs/pos/pos.md
+++ /dev/null
@@ -1,36 +0,0 @@
----
-pagination_prev: null
-pagination_next: null
----
-
-# MobilePay Point of Sale
-
-:::caution Change of Point of Sale in 2024
-
-Please notice that as part of the merger between MobilePay and Norwegian Vipps, we will consolidate products on one joint platform.
-In the beginning of 2024 we will therefore replace the current Point of Sale API with a new and scalable version.
-[See more here](/docs/pos/transition-to-one-platform)
-
-:::
-
-MobilePay PoS is a solution for customers to pay through their mobile via a QR code or the white MobilePay box.
-
-In order to use MobilePay PoS, the checkout system must be online, and the PoS integrator must support MobilePay.
-
-Our MobilePay PoS REST api is intended for software developers implementing MobilePay payments in a PoS system
-
-The MobilePay PoS API exposes two separate flows for payments which are documented in this section. All payments must be explicitly captured by the client after the customer has approved the payment. The capture amount can be for the full or a partial amount.
-
-
-
-Our MobilePay Point of Sale (PoS) REST API is intended for integrators implementing MobilePay payments in a PoS system.
-
-This document will explain in more detail how to implement the different payment flows, how to manage the PoS, how the Security model is built and what is needed from the integrator.
-
-This document does not include detailed specification of the endpoints, responses and response codes. This information can be found in the [API section](/api/pos).
-
-## Payment experience
-
-MobilePay PoS is an API for setting up a merchant's transaction requests on customers' MobilePay apps in a store. MobilePay PoS does not require the customer to manually enter any information in the MobilePay app pertaining to the transaction. A transaction request can typically be obtained by the customer by holding the mobile device near a merchant device (Terminal, BLE beacon, etc.) or scanning a QR code.
-
-Currently MobilePay PoS uses BLE one-way and two-way beacons and QR-codes to set up the transaction requests - the technology choices are not important for the API - however the concept of a beacon ID is central to allow matching of the customer willing to pay and the merchant's transaction request.
diff --git a/docs/pos/release-notes.md b/docs/pos/release-notes.md
deleted file mode 100644
index ae99b3204..000000000
--- a/docs/pos/release-notes.md
+++ /dev/null
@@ -1,293 +0,0 @@
----
-sidebar_position: 13
----
-
-# PoS API Release Notes
-
-The Point of Sale API V10 is now in production.
-
-## Changelog
-
-#### 2022-08-12
-
-- Introduced error code 1368 to [API Errors](/docs/pos/api-errors) and edited description on refundflow in [Refund Flow](/docs/pos/payment-flows/refunds)
-
----
-
-#### 2022-07-28
-
-- Introduced error code 1204 to [API Errors](/docs/pos/api-errors)
-
----
-
-#### 2022-05-25
-
-- Made it clear that directly using the `pollDelayInMs` response can improve payment flow completion time in [API Principles](/docs/pos/api-principles).
-
----
-
-#### 2022-05-03
-
-- Removed information regarding a now decomissioned migration endpoint.
-
----
-
-#### 2022-04-08
-
-- Created optimal flow section under [Best practices](/docs/pos/best-practices).
-
----
-
-#### 2021-08-11
-
-- Made it clear that it is the `beaconId` that should be used in [QR code generation](/docs/pos/create-qr-codes) instead of `posId`.
-
----
-
-#### 2021-08-04
-
-- Made it clear that Integrator's notification endpoint must return 200 on success in [Notification Service](/docs/pos/notification-service#notification-endpoint)
-
----
-
-#### 2021-05-25
-
-- Expanded list of valid characters in [Input Formats](/docs/pos/input-and-output-formats#valid-characters)
-
----
-
-#### 2021-03-23
-
-- Added `requirePaymentBeforeCheckin` documentation to [PoS management](/docs/pos/pos-management#preventing-checkin-before-payment)
-
----
-
-#### 2021-03-22
-
-- Added explicit retry suggestions and rules in [Retrying requests](/docs/pos/api-principles#retrying-requests)
-
----
-
-#### 2021-03-16
-
-- Removed CalibrationType property from [Input Formats](/docs/pos/input-and-output-formats#point-of-sales) since it has been removed from the V10 API.
-- Made the [Detecting MobilePay by notification service](/docs/pos/detecting-mobilepay#notification-service) section more clear by adding the call ``GET /pointofsales/{posid}/checkin`` to the flow diagram
-
----
-
-#### 2021-03-09
-
-- Re-wrote the [Onboarding](/docs/pos/pos-management#onboarding) section of the Point-of-Sale Management page. The section now contains a description on how to acquire store information needed for integrators when onboarding a merchant, which does not have a MobilePay PoS solution using an older version of the MobilePay PoS API.
-
----
-
-#### 2021-01-29
-
-- Added guide to [Create QR Codes](/docs/pos/create-qr-codes)
-
----
-
-#### 2020-12-15
-
-- Added section to [Refund Flow](/docs/pos/payment-flows/refunds) regarding how to get a `paymentId` for a refund if the `paymentId` is not known.
-
----
-
-#### 2020-10-23
-
-- Clarified language in the network and server errors paragraph of [API principles](/docs/pos/api-principles#error-handling).
-- Added desciption of why it is important to either capture or cancel a refund in error situations in [Cancelling refunds](/docs/pos/payment-flows/cancel-flows).
-- Removed age validation from documentation since this is not possible to do.
-
----
-
-#### 2020-10-20
-
-- Added error codes 1406, 1407, 1408, 1409, 1410, and 1411 to [API Errors](/docs/pos/api-errors).
-
----
-
-#### 2020-10-13
-
-- Refund functionality now ready and live in prod. See [Refund Flow](/docs/pos/payment-flows/refunds) for documentation on how to implement the functionality. An integrator needs to be certified in the new Refund section on the self certification website, to use the refund endpoints in the production environment. Also see the MobilePay developer portal to check out the API documentation.
-
----
-
-#### 2020-09-18
-
-- Removed the following supportedBeaconTypes: `BluetoothOther`, `BluetoothMP1`, `BluetoothMP2`, `BluetoothMP3`, `BluetoothMP4` and replaced them with one `Bluetooth` in [Input Formats](/docs/pos/input-and-output-formats). During certification when calling ``POST /pointofsales`` the request will now fail if supportedBeaconTypes contains any of the removed mentioned values above. If you already have a client that is certified and is using the old values, they will continue to work in production.
-
----
-
-#### 2020-09-14
-
-- Added 1365, 1366, 1367 error codes to [Api Errors](/docs/pos/api-errors)
-
----
-
-#### 2020-09-08
-
-- Removed Integrator ID from [Self Certification](/docs/pos/development-guide/verification)
-- Updated screenshots in [Self Certification](/docs/pos/development-guide/verification)
-
----
-
-#### 2020-09-02
-
-- Changed and updated how Refunds is planned to work. See description in [Payment Flows](/docs/pos/payment-flows/refunds). Release of Refunds are planned to Ultimo September.
-- Clarified how to choose a beaconId in [Best Practices](/docs/pos/best-practices#choosing-a-beaconid)
-
----
-
-#### 2020-08-19
-
-- Clarified the requirements for using long lived access tokens in [Authentication](/docs/pos/authentication)
-- Reduced the number of test cases in Self Certification by e.g. having more than one error or timeout scenario in one test case. Categories remain the same and this does not require a re-certification since this has not changed what is being tested.
-- Updated picture of Onboarding cases in [Self Certification](/docs/pos/development-guide/verification)
-- Removed x-mobilepay-client-system-name header from table in [Input Formats](/docs/pos/input-and-output-formats)
-- Please do not hesitate to provide feedback
-
----
-
-#### 2020-08-07
-
-- Added a section on [Best Practices](/docs/pos/best-practices) regarding Merchant onboarding.
-- Moved information regarding Partial Capture from [Best Practices](/docs/pos/best-practices) to [Payment Flows](/docs/pos/payment-flows/partial-capture) and added some diagrams describing the flow.
-- Removed the 403 forbidden statuscode when calling ``POST /payments/{paymentId}/capture`` from [API ERRORS](/docs/pos/api-errors)
-- Added a 409 conflict statuscode when calling ``POST /payments/{paymentId}/capture`` from [API ERRORS](/docs/pos/api-errors) that descibes if a partial capture is attempted on a payment where that is not possible.
-
----
-
-#### 2020-07-13
-
-- Added a 403 error code for payments/{payid}/capture in [API ERRORS](/docs/pos/api-errors) which is returned when trying to make a partial capture which is still not supported. When it will be possible to do partial captures it will be listed here in the release notes.
-
----
-
-#### 2020-07-10
-
-- Clarify handling timeout for POST/DELETE/PUT in [API principles](/docs/pos/api-principles#error-handling)
-
----
-
-#### 2020-06-29
-
-- Updated payment lifetime in [Payment Flow](/docs/pos/payment-flows/payment-flow)
-
----
-
-#### 2020-06-24
-
-- Updated description and added configuration details in [Self Certification](/docs/pos/development-guide/verification)
-
----
-
-#### 2020-05-14
-
-- Added error 1182 in [API ERRORS](/docs/pos/api-principles)
-
----
-
-#### 2020-05-13
-
-- Added a note on partial capture handling in [Best Practices](/docs/pos/best-practices)
-
----
-
-#### 2020-04-28
-
-- Added a note on the possibility of long-lived access tokens for PoS devices
-
----
-
-#### 2020-04-21
-
-- Added 403 in the API Errors section as a possible non-successful status-code when creating a Point of Sale.
-- Added a conflict case to the capture payment endpoint in the API Errors section when trying to capture an already captured payment with a different amount.
-
----
-
-#### 2020-03-27
-
-- Dropped the `x-ibm-client-system-name` header and modified the [API principles](/docs/pos/api-principles) page to explain how the `x-ibm-client-system-version` header will be used for client versioning.
-
-- Renamed all `X-IBM-*` and `X-MobilePay-*` headers to be lowercase in the documentation (the actual headers are case-insensitive).
-
----
-
-#### 2020-03-26
-
-- Renamed `vat_number` parameter to `merchant_vat` for [Authentication](/docs/pos/authentication) endpoint and changed the format to remove the dash between country code and VAT (e.g., "DK12345678" instead of "DK-12345678").
-
-- Removed 'api/' as part of the endpoint route for all endpoints.
-
----
-
-#### 2020-03-25
-
-- Added a *RejectedByMobilePayDueToAgeRestrictions* [payment state](/docs/pos/payment-flows/payment-flow), to indicate that a payment could not be completed because of age restrictions on the payment.
-
-- Added section Authentication [Authentication](/docs/pos/authentication) section so Integrators can use MobilePay APIs, as they'll have to obtain an access_token from the Integrator Authentication service. This way, MobilePay knows who is calling our service.
-
----
-
-#### 2020-03-04
-
-- Added section Handling Timeouts in [API Principles](/docs/pos/api-principles) section.
-
-- Removed a 409 errorcode from POST /api/v10/refunds regarding refund amount in the [API Errors](/docs/pos/api-errors) section and added an extra one regarding call to POST /api/v10/refunds if payment is not captured.
-
----
-
-#### 2020-03-03
-
-- Renamed header from X-MobilePay-MerchantVatNumber to X-MobilePay-Merchant-VAT-Number in the [Input Formats](/docs/pos/input-and-output-formats) section.
-
-- Rewrote parameters to camelCase instead of PascalCase in the [Input Formats](/docs/pos/input-and-output-formats) section to reflect the right casing in the API
-
----
-
-#### 2020-02-27
-
-- Added HTTP StatusCodes and ErrorCodes pr. endpoint in the API. Response codes have also slightly changed in the API on the basis of this documentation so be aware of minor changes to the API as well. See more at [API Errors](/docs/pos/api-errors).
-
-- Added header to all endpoints in the API called X-MobilePay-MerchantVatNumber. For more information see [Input Formats](/docs/pos/input-and-output-formats#http-headers)
-
-- Fixed wrong header name from X-IBM-ClientId to X-IBM-Client-Id. See [Input Formats](/docs/pos/input-and-output-formats#http-headers)
-
----
-
-#### 2020-02-07
-
-- Added documentation on payment restrictions under [Input Formats](/docs/pos/input-and-output-formats#payment-restrictions) and expanded on best practices regarding payment restrictions [Best Practices](/docs/pos/best-practices)
-
----
-
-#### 2020-02-04
-
-- Specified expiration length of Refund reservations to 24 hours. [Refunds](/docs/pos/payment-flows/refunds)
-
----
-
-#### 2020-01-31
-
-- Added a description of Self-Certification to the documention under [Self Certification](/docs/pos/development-guide/verification)
-
----
-
-#### 2019-12-23
-
-- Changed the month that news will come out regarding self-certification from December 2019 to January 2020
-
----
-
-#### 2019-12-10
-
-- Added `BrandName` to the subpage **Input and Output Formats** in the Brand section
-- Renamed subpage **Input Formats** to **Input and Output Formats**.
-- Adjusted content of subpage **Input and Output Formats**
- - **HTTP Headers**
- - Renamed from `X-MP-\*` to `X-MobilePay-\*`.
- - Removed `X-MP-IntegratorId`.
- - **Payments**
- - Added `PlannedCaptureDelay`, `CustomerToken` and `CustomerReceiptToken`.
diff --git a/docs/pos/resources.md b/docs/pos/resources.md
deleted file mode 100644
index e7d5dd92c..000000000
--- a/docs/pos/resources.md
+++ /dev/null
@@ -1,29 +0,0 @@
----
-sidebar_position: 16
-pagination_next: null
----
-
-# Resources
-
-[API documentation](/api/pos): The API reference documentation for PoS
-
-[Partner site](https://www.mobilepaygroup.com/partner/point-of-sale): Integrator onboarding and business information
-
-MobilePay site [DK](https://www.mobilepay.dk/erhverv/fysiske-butikker/mobilepay-point-of-sale) | [FI](https://mobilepay.fi/yrityksille/myyntipisteet/mobilepay-point-of-sale): Product information and support for merchants
-
-[Design Guidelines](https://www.mobilepaygroup.com/design): Find MobilePay buttons, logos, banners etc.
-
-Order PoS stickers and signs in the [web shop](https://mp.bordingcentral.dk/user/Login.aspx)
-
-Templates for creating PoS signs can be found here:
-
-* DK: [Materialebank](https://mobilepay.dk/materialebank/marketingmateriale/skilte/skiltning-til-pos)
-* FI: Please contact business.support@mobilepay.fi
-
-# Migration
-
-Information about the [new integration](https://www.mobilepaygroup.com/partner/new-platform)
-
-[Migration guide](https://developer.vippsmobilepay.com/docs/mp-migration-guide/pos/) covering the technical details of the new migration
-
-As a merchant - Requst access to [test environment](https://www.mobilepaygroup.com/partner/merchant-test)
diff --git a/docs/pos/transition-to-one-platform.md b/docs/pos/transition-to-one-platform.md
deleted file mode 100644
index 6832ef57e..000000000
--- a/docs/pos/transition-to-one-platform.md
+++ /dev/null
@@ -1,40 +0,0 @@
----
-sidebar_position: 15
----
-import Launch from '/docs/shared-blocks/_launch.mdx';
-
-# Transition to One Platform
-
-**One platform – more reach**
-
-On November 1st 2022 the merger between MobilePay and Norwegian Vipps was approved. We have now set full speed on the transition towards having one joint platform to become the best and most used payment wallet in the Nordics for you as customers and partners and for our users.
-Early 2024, the ambition is to have one app, branded locally as MobilePay in Denmark and Finland and Vipps in Norway, and one platform with more than 11 million users and more than 400.000 merchants across the Nordics.
-
-## Shift to a new API early 2024
-
-To allow for the flexibility and reach that we aim for, we will have to replace the current MobilePay Point of Sale API with new APIs on the new joint platform by early of 2024. This will require a new integration.
-
-**Nordic Wallet Launch 🚀** - this will be the the day when all MobilePay users will get new, updaraded app version. On the same date Invoice APIs will stop working and you will have to switch your trafic to ePayments APIs.
-- **March 12th** we will launch the new platform in **Denmark** and migrate all Danish merchants.
-
-## New integration
-
-We will continually send out information to all existing integrators about the new integration. To read more about the solution replacing MobilePay PoS please find details [here](https://www.mobilepaygroup.com/partner/new-platform). On this page you can also request access to the test environment to initiate the new integration work.
-For technical changes of the integration please visit the [migration guide](https://developer.vippsmobilepay.com/docs/vipps-developers/mp-migration-guide/#point-of-sale-vs-epayment). As soon as we have more information on the documentation for the new version, we will update these page.
-
-:::info Prepare for launch
-