> **Description:** Visual walkthrough of the in-person payment flow for PSPs using card passthrough with the ePayment API. > **AI agent:** Read [https://developer.vippsmobilepay.com/docs/knowledge-base/ai-tools.md](https://developer.vippsmobilepay.com/docs/knowledge-base/ai-tools.md) first. It covers keeping API keys and secrets out of generated code. > **Full site overview:** For an overview of the entire site, read [https://developer.vippsmobilepay.com/llms.txt](https://developer.vippsmobilepay.com/llms.txt). # How the ePayment PSP API works in person How in-person payments work for PSPs using `CARD_PASSTHROUGH` with the ePayment API. ## Details ### 1. The merchant adds the customer's products to the POS Add the products that the customer wants to buy in the point of sale. Screenshot: POS system showing a list of items on the left and payment method options on the right, including a highlighted "Pay with Vipps" or "Pay with MobilePay" button alongside card, cash, and other options. ### 2. Enter the customer's phone number When the customer is ready to pay, choose *Pay with Vipps/MobilePay* and enter the customer's phone number. Screenshot: POS system showing order items on the left and a phone number input field with a Next button on the right. ### 3. The payment request is sent to Vipps MobilePay Confirming the phone number triggers the payment request. The merchant's system, or the PSP's platform on the merchant's behalf, sends a [`POST:/epayment/v1/payments`](https://developer.vippsmobilepay.com/redocusaurus/epayment-swagger-id.yaml) request with: * `paymentMethod.type` set to `CARD_PASSTHROUGH` * `userFlow` set to `PUSH_MESSAGE`, which sends a push notification directly to the customer * `"customerInteraction": "CUSTOMER_PRESENT"` (required by regulation for in-person payments) * [`psp`](https://developer.vippsmobilepay.com/docs/APIs/psp-epayment-api/epayment-psp-api-guide.md#psp) object with the PSP's server URL specified in the `callbackUrl` field * [Other required parameters](https://developer.vippsmobilepay.com/docs/APIs/psp-epayment-api/epayment-psp-api-guide.md#parameters) For a full example, see [Create an in-person payment](https://developer.vippsmobilepay.com/docs/APIs/psp-epayment-api/epayment-psp-api-guide.md#create-an-in-person-payment). ### 4. The customer selects a card and confirms in the app The customer gets a push notification, opens their Vipps or MobilePay app, selects a stored card, and confirms the payment. Screenshot: App payment screen showing the merchant name, order description, selected payment card, and a Pay button. ### 5. The merchant learns the outcome from webhooks and polling The merchant's system has no visibility into what happens in the app, so a webhook is how it learns that the payment will not be completed: * `epayments.payment.aborted.v1`: the customer canceled the payment in the app. * `epayments.payment.expired.v1`: the customer did not confirm the payment in time, 10 minutes by default. On either event, the merchant's system releases the sale in the POS, so the attendant can try again or take another payment method. No card callback follows, and the flow ends here. Register the webhook before sending the payment request, so no event is missed while the customer is paying. See [Webhooks](https://developer.vippsmobilepay.com/docs/APIs/psp-epayment-api/epayment-psp-api-guide.md#webhooks) for what to register as a PSP and how to handle the events. ### 6. Vipps MobilePay sends the card token to the PSP When the customer confirms the payment and selects their card, Vipps MobilePay sends a card token to the PSP's `psp.callbackUrl`. ### 7. The PSP processes the payment and responds to the card callback The PSP processes the payment through its own acquiring infrastructure using the card token, then responds to the callback within 20 seconds. See [Card callback](https://developer.vippsmobilepay.com/docs/APIs/psp-epayment-api/epayment-psp-api-guide.md#card-callback) for the request format, HMAC authentication, and expected response. A `RESERVE` response reserves the amount for a later capture; it does not move the money. The payment is now authorized, and the merchant's system can confirm this through the `epayments.payment.authorized.v1` webhook. ### 8. The PSP confirms the payment to the POS and to Vipps MobilePay The PSP tells the merchant's system that the payment succeeded, so the POS can complete the sale. Screenshot: POS system showing order items on the left and a large green checkmark with "Payment completed" on the right, indicating successful payment registration. The PSP captures the payment in its own systems. It then sends a capture request to the ePayment API, which does not move any money; it only tells Vipps MobilePay to update the status so the customer sees the payment as captured in their app. The payment is transferred to the merchant's account through the PSP. This may take 2 or 3 days, depending on the bank. Refunds and cancellations use the same endpoints, but happen later and only if something goes wrong. See [Update payment status](https://developer.vippsmobilepay.com/docs/APIs/psp-epayment-api/epayment-psp-api-guide.md#update-payment-status). ## Sequence diagram In-person payment flow for PSPs ```mermaid sequenceDiagram autonumber actor C as Customer participant PSP as Merchant/PSP participant ePayment as ePayment API participant Webhooks as Webhooks API PSP->>PSP: Add products to the sale in the POS C->>PSP: Provide phone number PSP->>ePayment: Initiate payment with CARD_PASSTHROUGH and userFlow PUSH_MESSAGE ePayment->>C: Send a push message requesting payment C->>ePayment: Select a card and click pay Webhooks-->>PSP: Webhook: the payment was aborted or expired PSP->>ePayment: Poll for payment info, as a backup if the webhook is delayed or missed ePayment-->>PSP: Current state of the payment alt The payment was aborted or expired PSP->>PSP: Release the sale in the POS else The customer accepted the payment ePayment->>PSP: Card callback with the card token Note over PSP: Process the payment in its own acquiring systems PSP-->>ePayment: Respond to the callback with RESERVE within 20 seconds PSP->>PSP: Confirm the payment in the POS and complete the sale PSP->>ePayment: Send the capture status so the app shows it as captured end ``` PSP adds the products to the sale in the POS system. Customer provides their phone number. Merchant's system or PSP initiates the payment via the ePayment API with card passthrough and a push message user flow. ePayment API sends the customer a push message requesting payment. Customer selects a card and clicks pay. Webhooks API sends the merchant's system an aborted or expired event if the customer does not accept the payment. Merchant's system gets the payment from the ePayment API, as a backup if the webhook is delayed or missed. ePayment API returns the current state of the payment. If the payment was aborted or expired, the merchant's system releases the sale in the POS and the flow ends. If the customer accepts the payment, the ePayment API sends the card token to the PSP's card callback URL. PSP processes the payment in its own acquiring systems and responds to the callback with a reserve status within 20 seconds. PSP confirms the payment in the POS and completes the sale. PSP sends the capture status to the ePayment API, so the customer sees it as captured in the app. ## More information For technical details, see the [ePayment PSP API guide](https://developer.vippsmobilepay.com/docs/APIs/psp-epayment-api/epayment-psp-api-guide.md).