# Short-Term CC Data Storage Hyp allows merchants to reuse CVV2/CVC, which is considered sensitive card data, from a previous transaction in a secure, PCI DSS-compliant manner. Short-term credit card (CC) data storage refers to a session that securely retains CVV2/CVC for a brief 10-minute window after submission via the payment page. This allows the CVV2/CVC to be reused in a subsequent transaction without requiring the customer to re-enter it. ## When is short-term storage needed? Short-term storage supports a payment page flow that protects against network errors occurring between the customer submitting the payment page and the redirect to the merchant's success/failure page. In the [standard payment page flow](/creditguard/payment-page-integration/integrating-hyps-payment-page-and-accepting-payment.md), where the customer's card is charged immediately, a poorly timed network error may result in Hyp processing the charge without the merchant or customer receiving confirmation. If your customers frequently make purchases in environments with unstable internet connectivity, this can become a significant issue. To prevent this, you can use an alternative flow illustrated below that relies on short-term storage. ## How is short-term storage different from tokenization? [Tokenization](/creditguard/additional-payment-scenarios/tokenization.md) is designed for long-term storage and repeated use of the *credit card number*. It does not store CVV2/CVC. Short-term storage, by contrast, only saves CVV2/CVC for up to 10 minutes, allows its use in a single follow-up transaction, and then discards it. ## Short-term storage payment flows There are two main payment flows that take advantage of short-term storage: 1. **Capture with short-term storage**. This is the more common three-step flow that involves the following steps: 1. A payment page request configured for tokenization only, with the `keepCD` element set to `1`, initiating a short-term storage session. 2. A transaction inquiry that returns the session ID via the `sessionCD` element. 3. A follow-up capture transaction within the 10-minute window that references the session using the `sessionCD` element and sets `useCD` to `1`. 2. [**Two-phase commit**](/creditguard/two-phase-commits/overview.md) **with short-term storage**. Use this flow if you want to both guard against network errors and allow time between holding funds and charging them. It consists of four steps: 1. A payment page request configured for tokenization only, with the `keepCD` element set to `1`, initiating a short-term storage session. 2. A transaction inquiry that returns the session ID via the `sessionCD` element. 3. An authorization transaction within the 10-minute window that references the session using the `sessionCD` element and sets `useCD` to `1`. 4. A capture transaction to charge the customer's card, occurring within 5 days of authorization, that uses the `cgUid` value returned by the authorization step. ## Implementing capture with short-term storage First, let's look at how you can implement the shorter three-step flow. ### 1. Request a payment page for tokenization only First, make a [payment page request](/creditguard/payment-page-integration/integrating-hyps-payment-page-and-accepting-payment.md) with the `keepCD` element set to `1` to indicate that you want to save the CVV2/CVC in a short-term session. Set `mpiValidation` to `Token` to specify that you only want to tokenize the card and not charge it: ```xml 2000 ENG doDeal {terminalNumber} CGMPI {totalAmount} Debit RegularCredit ILS Internet TxnSetup {mid} {uniqueId} Token 1 {successUrl} {errorUrl} ``` You then proceed as usual, extracting the payment page URL from the response and redirecting the customer to it. Your success page in this flow should differ from the [standard payment page flow](/creditguard/payment-page-integration/integrating-hyps-payment-page-and-accepting-payment.md). Since you initially only tokenize the customer's card, the payment is not yet complete when the customer is redirected to your success page. The success page should either indicate that the customer will be charged soon or display a progress UI until you perform the capture transaction. After the customer submits the payment page and Hyp redirects them back to your success page, save the `txId` value from the [payment completion redirect](/creditguard/payment-page-integration/integrating-hyps-payment-page-and-accepting-payment.md#handle-payment-completion-redirect). ### 2. Retrieve the short-term session with a transaction inquiry With the `txId` value in hand, make a [transaction inquiry](/creditguard/inquiring-transactions/overview.md) to obtain the `sessionCD` value, which will be required in the next step: ```xml 2000 ENG inquireTransactions {terminalNumber} mpiTransaction {mid} {txId} ``` The response should look like this:

Show response

```xml inquireTransactions 2025-08-27 13:30 119730366 000 Permitted transaction Permitted transaction 2000 Eng f2006b07-f8f7-4ec5-bb36-cf5d0638ebeb 5ee2a41f-bbc0-4abf-b629-eab045fe7d34 10000 ILS 1092880571131111 EN 0 SUCCEEDED 00 SUCCESS 000 Permitted transaction doDeal 2025-08-27 13:29 119730272 000 Permitted transaction Permitted transaction 2000 Eng 000 Permitted transaction 0882819014 1092880571131111 411111 411111******1111 16 XXXXXXXXXXXX1111 0428 Foreign Credit Foreign Visa Alphacard RegularDebit RegularCredit ILS Internet 10000 0 Token 001 001 169.150.226.165 300012 119730245 AshraitEmv 0 1 100 1f095bf93da01a7cffb830565e2dbe15bc801c2a570473768f3819632a9a846c 00 SUCCESS 0428 ```

From this response, save the following values: * `sessionCD`: the identifier of the short-term storage session that holds the customer's CVV2/CVC. * `cardId`: the token representing the customer's credit card. * `cardExpiration`: the card's expiration date. ### 3. Perform the capture transaction Finally, perform a server-to-server capture transaction that uses the CVV2/CVC stored in the short-term session. Include the following elements: * `useCD` set to `1`: indicates that you want to use an existing storage session. * `sessionCD`: the value saved in step 2, specifying which session to use. * `cardId`: the token saved in step 2, identifying the customer's card. * `cardExpiration`: the value saved in step 2, specifying the card's expiration date. ```xml 2000 ENG doDeal {terminalNumber} {cardId} {cardExpiration} {totalAmount} Debit RegularCredit ILS Internet AutoComm 1 {sessionCD} ``` The success response should look like this:

Show response

```xml doDeal 2025-08-27 15:11 119734862 000 Permitted transaction Permitted transaction Host Result Remote 00-SUCCESS 2000 Eng 000 Permitted transaction 0882819014 1092880571131111 411111 411111******1111 16 xxxxxxxxxxxx1111 0327 Foreign Credit Foreign Visa Alphacard RegularDebit RegularCredit ILS Internet 1000 AutoComm Absent NotValidated CreditCompany 2673794 50 086 706 7 169.150.226.166 300012 119734776 AshraitEmv 01 4121 516749554975 Absent 52 25082715113208828198627 CreditCompanyAuthorized 0 CGD 0 001101 x 0 00 1111000000 SUG_ISKA NoAuthNumber 0 100 ```

## Implementing a two-phase commit with short-term storage You can also combine short-term storage with a [two-phase commit](/creditguard/two-phase-commits/overview.md), where the third step is an authorization request that uses `sessionCD`, and the fourth step is a capture request that uses `cgUid` from the authorization step, since `sessionCD` can only be used once. ### 1. Request a payment page for tokenization only Request a payment page for tokenization, following [step 1 of the three-step flow](#id-1.-request-a-payment-page-for-tokenization-only) described above. ### 2. Retrieve the short-term session with a transaction inquiry Make a transaction inquiry to retrieve a short-term session ID, following [step 2 of the three-step flow](#id-2.-retrieve-the-short-term-session-with-a-transaction-inquiry) described above. ### 3. Perform the authorization transaction Within 10 minutes of a successful redirect from the payment page, perform an authorization request using the CVV2/CVC stored in the short-term session. Include the following elements: * `useCD` set to `1`: indicates that you want to use an existing storage session. * `sessionCD`: the value saved in step 2, specifying which session to use. * `cardId`: the token saved in step 2, identifying the customer's card. * `cardExpiration`: the value saved in step 2, specifying the card's expiration date. ```xml 2000 ENG doDeal {terminalNumber} {cardId} {cardExpiration} {totalAmount} Debit RegularCredit ILS Internet Verify 1 {sessionCD} ``` The success response should look like this:

Show response

```xml doDeal 2025-09-02 00:51 119837489 000 Permitted transaction Permitted transaction Host Result Remote 00-SUCCESS 2000 Eng 000 Permitted transaction 0882819014 1092880571131111 411111 411111******1111 16 xxxxxxxxxxxx1111 0327 Foreign Credit Foreign Visa Alphacard RegularDebit RegularCredit ILS Internet 10000 Verify Absent NotValidated CreditCompany 2577461 7 104.151.111.250 300012 119837435 AshraitEmv 01 4121 574608744851 Absent 52 25090200515908828194894 CreditCompanyAuthorized 0 CGD 0 001101 x 0 00 1111000000 SUG_ISKA, BAKASHA_LEISHUR_LELO_ISKA NoAuthNumber 0 100 ```

From this response, save the `cgUid` value that you'll need for the final step. ### 4. Perform the capture transaction Within 5 days of authorization, perform a capture transaction that uses the `cgUid` saved in step 3, as well as the `cardId` and `cardExpiration` saved in step 2: ```xml 2000 ENG doDeal {terminalNumber} {cardId} {cardExpiration} {totalAmount} Debit RegularCredit ILS Internet AutoComm {cgUid} ``` The success response should look like this:

Show response

```xml doDeal 2025-09-02 00:54 119837494 000 Permitted transaction Permitted transaction Host Result Local 00-SUCCESS 2000 Eng 000 Permitted transaction 0882819014 1092880571131111 411111 411111******1111 16 xxxxxxxxxxxx1111 0327 Foreign Credit Foreign Visa Alphacard RegularDebit RegularCredit ILS Internet 10000 AutoComm VoiceMail 2577461 06 086 864 7 104.151.111.250 300012 119837435 AshraitEmv 574608744851 4121 01 52 25090200515908828194894 1 0 2577461 10000 0902 1 005159 CreditCompanyPreAuthorized 25090200515908828194894 0 CGD 0 0 001101 x 0 1111000000 NoAuthNumber 0 100 ```

## FAQ ### What is `sessionCD`, and how long is it valid? `sessionCD` is an identifier for a short-term storage session that securely retains the CVV number from a previous transaction. It allows reusing the CVV without requiring the customer to enter it multiple times in the same flow. A `sessionCD` is valid for 10 minutes, can be used exactly once, and expires immediately after use. ### Which Hyp payment flows support short-term storage? `sessionCD` and short-term storage are only supported in payment page flows, not in direct server-to-server requests. ### Can the same `sessionCD` be reused for multiple transactions? No. A `sessionCD` is valid for one-time use only and expires automatically afterward. ### Do I still need to use a token when I use `sessionCD`? Yes. `cardId` is a token for the credit card number and is required when using `sessionCD`. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://developers.hyp.co.il/creditguard/additional-payment-scenarios/short-term-cc-data-storage.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.