Introduction to Stored Value Accounts

A Stored Value Account (SVA) is a financial account used to store digital money on a customer's eWallet, or what is sometimes referred to as a digital wallet. SVAs are conveniently accessed from the internet using devices like smartphones, tablets, or from a website.

To use an SVA, digital cash is loaded to the SVA account using separate funding sources such as credit cards, bank accounts, or transferred from another person’s SVA account.

The use of SVA accounts include, but are not limited to the following:

  • Ecommerce purchase
  • Payment to merchant/store
  • Money transfer to friends and relatives.

Manage SVA Funds

The APIs listed below are all required for the management of an SVA. From the initial SVA creation to the management of funds stored on an SVA.

  • Create Account Creates the SVA and the money container associated with the stored value account.

  • Get Account Balance - Retrieve the balance of the SVA’s money container.

  • Remove Money Container - Removes the functionality of a money container, but does not remove it completely from the system. For auditing purposes, we keep the last 4 digits of the account number if any suspicious activity occurs.

Use Cases

The purpose of this section is to describe a variety of scenarios and to describe the user's interaction required for payment processing.

Add Credit Cards to an eWallet

Credit cards are added to an eWallet to fund an SVA account or to authorize payments made by the Add Money Account API.

Note: For security, all credit card data is stored in the system per PCI DSS requirements.

SVA Cash In APIs

Here’s how to add money to a new SVA, or to replenish funds onto an existing SVA.

  • Execute - LoadSVAFromCC - This is the transfer between two existing money containers that belong to a Consumer. Funds are transfer from a Credit Card via Money Container to an SVA via a separate Money Container.
  • Deposit to SVA - A Company User who has access to corporate financial accounts is able to deposits funds to a Company's Stored Value Account (SVA).
  • P2P - Person to Person transfer - This is the transfer between two money containers; each belonging to a separate person.

    • This section examines the phases of payment, and the steps involved in each phase through a variety of use cases. The purpose of this section is to describe a variety of scenarios present in each step of a payment process.

    Make a Purchase using an SVA

    A Consumer can make payments using funds from their Stored Value Account (SVA). To pay using an SVA, the consumer performs the following steps:

  • The Consumer must first register using the Self Register API.
  • Once registered, the Consumer authenticates using the Get Token API.
  • The Consumer creates an SVA for the purpose of storing funds using the Create Account API.
  • The Consumer adds an existing Credit Card using the Add Money Container API.
  • The Consumer loads funds from the Credit Card to the SVA using the Execute - LoadSVAFromCC API.
  • With the existing funds on an SVA, the Consumer is able to make a purchase using the Execute - Purchase API.

    • Make a Purchase using a Credit Card already added to an eWallet

    Once a user has added a credit card to their wallet, the user can pay directly from their credit card using the Debit API.

    The steps for making a purchase are:

  • The Consumer must first register in MoTEAF using the Self Register API.
  • Once registered, the Consumer authenticates using the Get Token API.
  • The Consumer adds an existing Credit Card using the Add Money Container API.
  • The Consumer is able to execute the Execute - Debit API.

    • Make a Purchase by Swiping a Credit Card on a POS Terminal

    LiftCommerce configures and supports Point-to-Point encryption (P2PE) terminals for PCI-validated credit card processing. When paying at a Point of Sale (POS) Terminal using a credit card, the Pay With Card API is the first step that is triggered when a consumer is ready to make a payment at the store. This API initiates the call to the 3rd party gateway through ‘Switch’ so the user can swipe their card and their transaction is processed. The Payment Gateway either authorizes and approves the card information, or card authorization is denied.

    Prerequisites:

    • A PCI-compliant terminal device is available.
    • A store cashier or store representative (POS user) is already registered and authenticated in MoTEAF.

    The following items are verified and performed at a card swipe terminal:

    • The store cashier initiates a 10 minute session on the BOLT terminal by calling the Get Session Key API. A session must always be initiated before processing a payment with a credit card and is only optional if the payment gateway is an Invoice Processing Platform (IPP).

    The next steps the consumer makes for this type of purchase are: - The Consumer swipes their card on the POS terminal and the card gets approved or denied based on the authorization from payment gateway. - Card Connect, or any 3rd party payment gateway server processes the transaction and either approves or denies the request, and sends the response to our Switch connector which in turn sends it to POS MicroService as a response to Pay with Card API call. - Any errors returned from the BOLT terminal are listed in the Bolt Errors section.

    Note: The Pay with Card API is part of our POS Microservices APIs, included with the Payments API.

    Make a Purchase using Web Based Virtual Terminal

    Virtual terminals are web-based applications that allows merchants to accept credit card payments. This card-not present transaction is primarily used for collecting credit card details from a consumer who is calling the CSR representing a merchant from a phone. This solution enables merchants to take a payment without a card reader.

    The following steps are used to simulate a terminal.

    Prerequisite: - The Customer Service Representative (CSR) is already registered and authenticated into the portal.

    The following steps are then used to simulate the actions performed on a terminal.

    • A Consumer calls a Customer Service Representative (CSR) or the merchant.
    • From a phone, the CSR collects card details from the Consumer.
    • The CSR executes the Execute - CVT API after collecting information from the Consumer.

    SVA Cash Out APIs

    Digital money stored in an SVA can be transferred back to consumer’s bank or it can be cashed-out of the SVA by using an Money Transfer Code (MTC). Any of the following APIs can be used for a Cashout.

    • SVA Withdrawal Agent - A Company User who has access to corporate financial accounts can withdraw funds from a money container belonging to a Company's SVA and process a credit to the recipient's bank account money container. Both SVAs must belong to the same entity.

    • Send Money To MTC Code - This operation lets a Subscriber or a Company User transfer money from their SVA’s money container to a company holding account. These funds are only accessible through the use of a MTC that gets generated when the funds are placed into a company holding account. Funds are removed using the Encash MTC API at an agent or correspondent location.

    • Encash MTC - This operation lets a Subscriber or a Company User cash out from a money transfer. A recipient visits an agent location with the MTC that was generated from the Send Money to MT Code API. After verifying the recipient's identity and MTC, the Encash MTC is executed by a Company User such as an Agent, who then physically hands cash to the recipient.

    Cancel

    Credit card processing is performed in two stages. The first stage is authorization stage and the second is settlement. A small window exists between the two as to when to cancel a transaction without it affecting the customer's balance. If cancellation is not possible, a customer may require a refund. The Cancel API operation cancels any previous transactions that have been executed. By providing a Transaction ID, the transaction history can be accessed and all steps reversed.

    Refund Service

    A refund is used to return some or all funds on a transaction that are in the Settled status. Refund requests are automatically captured and if no amount is supplied, a refund for the full original payment amount is issued. To initiate a Refund with Reference, a call is made to the Refund API service, passing the: - Merchant ID - Retrieval Reference Number (retref) from original authorization. - The amount of the requested refund.

    Refund requests are automatically captured. Each individual cardholder's bank imposes a maximum time frame allowed to Refund with Reference. This can take up to six months following a transaction. To initiate a Refund without Reference, a call is made to the Authorization Service passing the amount of the refund as a negative value in the amount parameter. Refunds without Reference do not require a Retrieval Reference Number passed, but it is configured so our Merchants have this functionality.

    Get Transaction History

    The Get Transaction History API allows cashiers and store management to view information about cash deposits, cash withdrawals, inbound and outbound transfers, and internal transfers for accounts. Consumers may only view their own transaction history.

    Get Transaction Details

    The Get Transaction Details API, allows consumers or store managers view the details of any transaction. Consumers may only view the details of their own account.

    Error Codes from P2PE Bolt Reader

    Status Code Description
    200 Success
    401 Unauthorized
    403 Invalid HSN for MerchantID.
    500 Bolt Client or Server Error.

    To access the Switch APIs, see Switch.

    JSON