> **Description:** Master the two-phase payment process with Vipps MobilePay - learn how to reserve funds and capture payments at the right time for secure transactions. > **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 every page in this documentation, read [https://developer.vippsmobilepay.com/llms.txt](https://developer.vippsmobilepay.com/llms.txt). # Capture Capture is the process of moving funds from the customer's account to the merchant's account. Depending on your bank, this can take a few days. See [Settlements](https://developer.vippsmobilepay.com/docs/knowledge-base/settlements.md) for payout timing and records. The default type of capture is *reserve capture*, where the payment goes into the reserved state once authorized. *Direct capture* is a special type of capture, available only in the Recurring API and eCom API. With direct capture, the payment moves directly to the paid state and is captured immediately. This page focuses mainly on reserve capture, since it's the default flow. ## Reserve capture vs direct capture Only the eCom API and Recurring API support *direct capture*. - *Reserve capture* is the default. When you initiate a payment, it stays reserved until you capture it, whether that happens a few seconds later or several days later. - When *direct capture* is activated, all payment reservations are captured instantly. This is intended for situations where the product or service is provided to the customer immediately, with no chance that it turns out to be unavailable or sold out, for example digital services. - For the eCom API, direct capture requires additional compliance checks of the merchant. - For the Recurring API, direct capture is enabled by default. Diagram comparing two payment capture flows. Reserve Capture: Payment initiated -> Amount reserved (with optional cancel or partial capture) -> Final capture -> Settlement. Direct Capture: (1) Payment initiated (2) Immediate capture (3) Settlement. Some things to consider: - If a payment has been *reserved* (as with reserve capture), the merchant can make a `/cancel` call to immediately release the reservation and make the funds available in the customer's account. - If a payment has been *captured* (as with direct capture), the merchant has to make a `/refund` call, and it then takes several days before the amount is available in the customer's account. - With reserve capture, you can reserve a higher amount upfront and capture only what was actually used -- for example, when the final amount isn't known at the time of reservation, such as with electric car charging. You can also split the capture into multiple partial captures. If you're not sure which to use, choose reserve capture and just do the capture right after the reserve. The user experience is exactly the same. ## Reserve capture When you use *reserve capture*, the customer's funds go into the *reserved* state instead of being captured automatically. The funds stay in the customer's account, but aren't available for them to spend. You're obligated to wait until the products or services are ready to be delivered before you capture (see [Capture regulations](#capture-regulations)). Once the order is ready, capture as soon as possible -- payment reservations expire, and some financial institutions release the funds early, so they may no longer be there when you try to capture. **Capture considerations** - The capture must not happen before the goods are ready to dispatch, and you should only hand goods to the carrier after confirming the full amount was captured. - Reservations expire after a limited time (see [capture deadlines](#capture-deadlines) and [payment reservations may end before the payment expires](#payment-reservations-may-end-before-the-payment-expires)). A late capture can fail due to insufficient funds even if the payment was authorized at checkout. - Banks hold reservations for a set number of days, even with partial captures. The timer starts when the reservation is made, so be sure to complete all captures before it expires. - Always verify the response of the capture call to confirm the full amount was captured -- the HTTP status code alone isn't sufficient. Use an [idempotency key](https://developer.vippsmobilepay.com/docs/knowledge-base/http-headers.md#idempotency) in the capture call so the same request doesn't get created more than once. Screenshot: Vipps/MobilePay app showing a reserved payment of 500 kr for "Hoodie". Status is Reserved. Annotated labels indicate: Amount reserved, Amount authorized (reserved), and Reference (orderId). With reserve capture, you have the option of capturing the full amount (*full capture*), or doing a *partial capture*, where you capture only part of the amount. With [partial capture](#partial-capture), you can use multiple small captures until the reserved amount is used, or you could cancel any unused amount. If you don't plan to capture the entire amount, [cancel](https://developer.vippsmobilepay.com/docs/knowledge-base/cancel.md) the remainder as soon as possible for a good user experience. Once captured, returning funds requires a [refund operation](https://developer.vippsmobilepay.com/docs/knowledge-base/refund.md), which can take a few days. For details about bank payouts and records, see [Settlements](https://developer.vippsmobilepay.com/docs/knowledge-base/settlements.md). ### Partial capture **NOTE** Sales units in Denmark and Finland must request this through [customer service](https://help.vippsmobilepay.com/). With *partial capture*, part of the original authorized amount is captured, and the remaining amount continues to be available for capture. Partial capture can be collected many times, for as long as there is a remaining *reserved* amount. You should capture or cancel the remainder when the order is complete. See [Cancel a partially captured order](https://developer.vippsmobilepay.com/docs/knowledge-base/cancel.md#cancel-a-partially-captured-order). **Important** Be sure to capture the payment within the [payment capture deadlines](#capture-deadlines); otherwise it will be cancelled. Partial captures **do not** extend the reservation period. #### Example: EV charging with partial capture When the final amount isn't known at the time of the payment request -- for example with vending machines, charging stations, or taxis -- it's common to reserve a slightly higher (but reasonable) amount. This ensures the payment is authorized to cover the full cost of the service. Once the exact amount is determined, the merchant captures that amount and cancels the remaining reservation. For example: 1. Customer pays at EV charger via Vipps/MobilePay. 2. Merchant reserves **500 NOK** (final amount unknown). 3. Customer approves and charging starts. 4. After charging, actual cost is **250 NOK**. 5. Merchant captures **250 NOK** and cancels the remaining **250 NOK**. Screenshot: Vipps/MobilePay app showing a paid charging session of 250 kr. Transaction history shows a capture of −250 kr and an original reservation of 500 kr. Annotated labels indicate: Amount paid, Payment transferred (captured), and Amount authorized (reserved). See [Flows: Electric vehicle charging](https://developer.vippsmobilepay.com/docs/recommended-flows/ev-charging/README.md). ## Capture regulations By regulation, you must not capture a payment until the product or service is ready to be delivered to the customer. We comply with applicable local laws as well as guidance from the Norwegian Data Protection Authority, [Datatilsynet](https://www.datatilsynet.no/rettigheter-og-plikter/personopplysninger/fodselsnummer/), and other relevant local authorities. ## Capture deadlines If a payment isn't captured within the deadline below, it's automatically cancelled and can no longer be captured. In Norway, the time limit for capturing payments is 180 days. Be aware: [Payment reservations may end before the payment expires](https://developer.vippsmobilepay.com/docs/knowledge-base/reserve-and-capture.md#payment-reservations-may-end-before-the-payment-expires). In Denmark and Finland, the time limit for capturing payments is 14 days by default. Newer sales units, or sales units approved for [late capture](https://developer.vippsmobilepay.com/docs/knowledge-base/reserve-and-capture.md#late-capture-for-mobilepay-sales-units), may have a longer limit, up to 180 days. If you require more time, contact your KAM or [customer service](https://help.vippsmobilepay.com/). Attempting to capture a payment after its deadline returns `HTTP 400 Bad Request` with relevant error details. These deadlines are outer limits, not guarantees: the customer's bank, card issuer, Klarna, or other payment provider can release the reservation earlier -- see [Payment reservations may end before the payment expires](https://developer.vippsmobilepay.com/docs/knowledge-base/reserve-and-capture.md#payment-reservations-may-end-before-the-payment-expires). For this reason, always confirm that your capture request succeeded and that the entire amount was captured before you deliver the product. ### Late capture for MobilePay sales units Newer MobilePay sales units in Denmark and Finland may already have a capture deadline longer than 14 days, up to 180 days. Older sales units can request this on a case-by-case basis, if there's a legitimate business need -- the typical scenario is online retail, where goods are delivered later (for example, when the product isn't in stock), and capture must also happen later as a result. Contact your KAM or [customer service](https://help.vippsmobilepay.com/) to check or request this for your sales unit. Captures between 15 and 180 days after reservation are not guaranteed to succeed. The card may have expired, or have insufficient funds, by the time of capture. See [Payment reservations may end before the payment expires](#payment-reservations-may-end-before-the-payment-expires). ### Payment reservations may end before the payment expires We don't control how long a bank, card issuer, Klarna, or other payment provider holds a reservation -- it can end before the [payment capture deadlines](#capture-deadlines) above are reached. The information below is the most accurate we can provide, but specific details may vary. - **Visa:** Reservations usually last 5-7 days (5 days for Visa Electron). Banks release reservations after 4-7 days. If you capture within 7 days, Visa guarantees the capture will succeed. See [Visa reservations - Adyen docs](https://docs.adyen.com/online-payments/adjust-authorisation#visa). - **Mastercard:** Reservations are valid for 30 days, but banks may release them earlier. If you capture within 30 days, Mastercard guarantees the capture will succeed. See [Mastercard reservations - Adyen docs](https://docs.adyen.com/online-payments/adjust-authorisation#mastercard). > We can't change the status of a reservation once made. Behavior after reservation expiry If you try to capture after 7 days (Visa) or 30 days (Mastercard) -- and the bank has released the reservation -- we will attempt a new payment. If the account has enough funds, the payment will succeed. **This is the most common cause of failed captures for webshops shipping physical products.** Capture when the order is ready to dispatch, verify the response shows the full amount captured, and only then hand the goods to the carrier. If the account has insufficient funds, the payment may fail or, in some cases, succeed and put the account in the negative. Whether this is allowed depends on the customer's bank and account type. Other factors, like expired or blocked cards, can also prevent capture, and we cannot predict these outcomes in advance. In some cases, banks may force a capture through if possible, which could put the account in the negative. Be aware that customers may be dissatisfied if this happens. Attempting to capture an old payment (beyond the allowed window) will fail with an error -- see [API guides](#api-guides) below for the specific error for your API. **If a capture fails, delay sending goods to the customer until the issue is resolved** -- for example, deadline passed, funds already released by the bank, or a temporary error. See your API's guide, linked under [API guides](#api-guides), for the specific error you received and whether a retry makes sense. You may need to talk to the customer to collect the money another way. ## Troubleshooting ### Why does capture fail? The most common reasons are: 1. **Reservation expired -- insufficient funds:** Card networks only guarantee the reservation for a limited time (5-7 days for Visa, 30 days for Mastercard). Once expired, the bank releases the held funds and a capture attempt becomes a new charge that can fail if the customer has since spent those funds. Capture immediately before shipping, on the same day. Verify the response body confirms the full amount was captured before handing to the carrier. See [Payment reservations may end before the payment expires](#payment-reservations-may-end-before-the-payment-expires). 2. **Capture amount is higher than the reserved amount:** The customer approved a specific amount in the app, but you are attempting to charge more. 3. **The payment is not in a reserved state:** The customer has not yet approved the payment, or the payment was already captured or cancelled. 4. **The payment was automatically cancelled due to the capture deadline being exceeded.** See [payment capture deadlines](#capture-deadlines). All failed capture attempts get an error response from our API. The response contains the details of why the capture failed. If the reserved amount is too low for shipping costs to be included, the capture will fail. The reserved amount must be at least as high as the amount that is captured. Example: If the value of the shopping cart is 1000 NOK, and the reserved amount is 1200 NOK, the shipping cost can be maximum 200 NOK to be within the reserved amount of 1200 NOK. If the shipping cost is 300 NOK, a capture of 1000 + 300 NOK = 1300 NOK will fail. It's not possible to capture more than the reserved amount, as that would make this sequence possible: 1. The merchant initiates a payment of 1000 NOK. 2. The user confirms the 1000 NOK payment in the app. 3. The merchant captures 50 000 NOK from the user. Similarly, it's not possible to capture an amount that isn't reserved, as that would make it possible to charge a user's card without requiring the user to confirm the payment first. ### Customer reports being charged twice Some banks display both the reservation and the capture to customers, which can lead to confusion about being charged twice. This is actually the same payment shown at different stages, not duplicate charges. See [Investigating double charge reports](https://developer.vippsmobilepay.com/docs/knowledge-base/errors.md#investigating-double-charge-reports) for detailed steps on how to investigate and explain this to customers. ## Common questions ### For how long is a payment reserved? A payment is reserved until it is either captured, cancelled, or expired. For the number of days, see [payment capture deadlines](#capture-deadlines). ### When should I use "direct capture"? Only the eCom API and Recurring API support *direct capture*. If you aren't sure, use *reserve capture* and capture immediately after reserving. This has some benefits -- see [Reserve capture vs direct capture](#reserve-capture-vs-direct-capture). ### How can I check if I have "reserve capture" or "direct capture"? All merchants can log in to the [business portal](https://portal.vippsmobilepay.com) and check the capture type for all their sales units in the *Developer* section. You can also find information on how to change capture type there. We require BankID, FTN, or MitID login for this, as *direct capture* requires additional compliance checks. If you are a partner and want to check a merchant, see the [Management API](https://developer.vippsmobilepay.com/docs/APIs/management-api/README.md). If you are a partner and don't yet use the [Management API](https://developer.vippsmobilepay.com/docs/APIs/management-api/README.md), you can ask the merchant to [create a business portal user](https://developer.vippsmobilepay.com/docs/knowledge-base/portal.md#add-a-new-user) for you. Then, you can check on behalf of the merchant. If you are not able to log in to the [business portal](https://portal.vippsmobilepay.com), you can make a small payment (2 NOK), check the payment with [`GET:/ecomm/v2/payments/{orderId}/details`](https://developer.vippsmobilepay.com/redocusaurus/ecom-swagger-id.yaml), and cancel (if it was `RESERVE` and reserve capture) or refund (if it was `SALE` and direct capture). ### How do I turn direct capture on or off? You can't turn *direct capture* on or off as a merchant. A sales unit can only have one capture type, and we must configure that. **NOTE** We only offer *direct capture* to merchants that use Vipps MobilePay through a partner, and for merchants that have a Key Account Manager. *Direct capture* must be requested by the partner from the partner manager, or by KAM merchants from the Key Account Manager. See: - [Reserve capture vs direct capture](#reserve-capture-vs-direct-capture) ## API guides The following APIs have capture methods: - [ePayment API: Capture a payment](https://developer.vippsmobilepay.com/docs/APIs/epayment-api/api-guide/operations/capture.md) - [Recurring API: Capture a charge](https://developer.vippsmobilepay.com/docs/APIs/recurring-api/recurring-api-guide.md#capture-a-charge) - [eCom API (Vipps only and deprecated): Capture a payment](https://developer.vippsmobilepay.com/docs/APIs/ecom-api/vipps-ecom-api.md#capture)