Swipe event enumeration
This article explains swipe event types.
This documentation explains how LoanPro's swipe event types are handled and how they affect swipes.
| Event Type: | Adds to/Subtracts from: | Description + Use Case: |
|---|---|---|
authorization | +authorized-amount | This event is commonly the first event created on a swipe. This records the amount that was authorized for the swipe. |
preauthorization | +authorized-amount | This event is used when an amount requested to be authorized is an estimate or max amount from the merchant. This event is usually created by flagging a swipe as preauthorization swipe. This event is then followed up by an authorization-advice event that updates the authorized-amount to the actual authorized amount.This event will be used for something like an authorization at an Automated Fuel Dispenser (AFD). |
authorization-advice | updates authorized-amount to match event-amount | This event is used to update a pre-authorized amount to the actual authorized/requested amount of the swipe. This event will be created to update the authorized amount on a preauthorization swipe to the actual authorized amount for the transaction. This event may also be used if the network or issuer performs Stand In Processing (STIP) to authorize a swipe on LoanPro's behalf. If that is the case, the swipe will be flagged as authorization-advice when it's created by setting the authorization-advice flag to true.This event will be used for something like updating the authorized amount of an Automated Fuel Dispenser (AFD) transaction. |
additional-authorization | +authorized-amount | This event is used to request additional authorization on an existing swipe. This authorization will be evaluated for approval by LoanPro, and it will increase the authorized amount of the initial swipe that is being created for if it is approved. This swipe event could be used in situations such as ride-sharing transactions. For example, if the cardholder decides to alter the trip during the ride, their card is authorized multiple times as part of the same swipe. This is also common in hotels and rental cars when cardholders extend their usage time of the product. |
credit-authorization | +authorized-credit-amount | This event allows a merchant to authorize a credit to the borrower. This event will be created in LoanPro by creating it as a new swipe and flagging the new swipe as a credit-authorization. This credit will later be cleared by the merchant.This event is used when a cardholder returns something that was purchased, or when the merchant gives the cardholder a credit for some other reason. This even will only rarely be created on an existing swipe. |
clearing | +cleared-amount | This event follows the authorization type event. This event is sent when a merchant clears the funds requested by one of the authorization events - money moves from the card issuer's account to the merchant acquirer's account. |
clearing-reversal | -cleared-amount | This event is used to update a Single Message Authorization (SMA) swipe that was authorized by LoanPro but was later declined in the authorization path by either the issuing processor or the acquirer and LoanPro was later notified of the decline. Once LoanPro is notified of the decline, it will use void and clearing-reversal events to essentially "cancel out" the authorization and clearing events from the swipe that was created. This is necessary because LoanPro approved the SMA authorization that was previously requested, thus, an authorization and clearing event were both created by the approved authorization request.This event will subtract from the cleared amount of a swipe. This swipe event should never be created via the swipe event creation endpoint. This event will be created automatically by LoanPro when a void event is created on a swipe that has been flagged as SMA. |
forced-clearing | +cleared-amount | This event is used to show that a merchant charged a card without requesting authorization first. This event will only be created when a swipe has its forced-clearing flag set to true. The forced-clearing flag will be set to true on a swipe if LoanPro receives a clearing type event from the issuing processor with no prior authorization type event to link it to. The issuing processor may also flag swipes as forced-clearing swipes before they are sent to LoanPro. |
credit-clearing | +credit-cleared-amount | This event will follow the credit-authorization type event.This event occurs when funds requested by one of the credit-authorization events clears. |
credit-clearing-reversal | -credit-cleared-amount | This event will be used to update a SMA (Single Message Authorization) swipe that was authorized but later declined. When this event occurs, void and credit-clearing-reversal events are used to cancel out the credit-authorization and credit-clearing events on the swipe. |
credit-forced-clearing | +credit-cleared-amount | This even will be used to show that credit was applied to a card without credit authorization. This event will be created when a swipe has its force-clearing and credit-authorization flags set to true. The force-clearing and credit-authorization flags will be set to true on a swipe if LoanPro receives a credit-clearing type event from the issuing processor with no prior authorization type event to link it to. The issuing processor may also flag swipes as credit-forced-clearing swipes before they are sent to LoanPro. |
void | +voided-amount | This event is used to free up an outstanding authorized amount on a swipe. The outstanding authorized amount on a swipe = authorized-amount - (cleared-amount + voided-amount)A merchant may send a void event if a purchase is made but will not be completed for some reason. In other words, funds were authorized for a purchase, but they were never cleared. This even will remove the hold on authorized funds so that they may be spent elsewhere. |
authorization-expired | +voided-amount | This event, like the void event, is used to free up an outstanding authorized amount on a swipe.However, this event differs in that it is initiated by the issuing processor. Essentially, this event is used to free up funds that were authorized by a merchant but were then never cleared or voided by the merchant. |
automatic-authorization-expired | +voided-amount | This event is similar to the authorization-expired event; and to LoanPro users, it will mean the same thing.The difference between this event and the authorization-expired event is that this one will be internally generated by LoanPro when a swipe has reached a user-specified number of days after its creation if an outstanding authorized amount still exists on the swipe.( authorized-amount - (voided-amount + cleared-amount)) ≠ 0The automatic swipe expiration days setting is found in the card program settings and is set when a card is created. Exceptions to the automatic swipe expiration days setting can also be specified. There are some scenarios where an issuing processor may send an authorization-expired swipe event to LoanPro without tying it to the initial swipe that it's created for. This event will be used as a fail-safe to free up held funds in the event that the merchant and the issuing processor do not tie a void event or an authorization-expired event to an initial swipe when they are supposed to. This ensures funds are not held indefinitely on a card without being cleared. |
credit-void | +voided-credit | This event is used to free up an outstanding credit authorized amount on a swipe. The outstanding credit authorized amount on a swipe = ( authorized-credit-amount - (cleared-amount + voided-amount))This circumstance may occur if a credit-authorization is requested but cannot be completed for some reason. |
dispute-requested | +dispute-requested-amount | This event is used to record if a cardholder has requested to dispute any amount on a swipe. This event just records that the request was made - it does not credit the cardholder any amount. |
dispute-denied | +dispute-denied-amount | This event is used to track if a requested dispute amount or an amount that was given as provisional credit has been denied - meaning the transaction was proven to be legitimate and the cardholder lost the dispute. This event only has significance when a dispute-provisional-credit event has been created on a swipe. In this case, it will remove the provisional credit that was given to the cardholder. |
dispute-provisional-credit | +dispute-provisional-credit-amount | This event is used to award a provisional credit for a disputed amount. A provisional credit does not mean that the cardholder has won the dispute; it means that the dispute was deemed worthy of investigation. This credit may be removed from the card's line of credit account if the dispute is lost using a dispute-denied event. If the cardholder wins the dispute, this credit will become permanent, using a dispute-write-off or dispute-chargeback event. |
dispute-write-off | +dispute-write-off-amount | This event is used to track when a dispute is won by the cardholder and the card issuer is liable for the transaction. In this circumstance, the credit that was given for the disputed amount is taken as a loss by the card issuer/lender. |
dispute-chargeback | +dispute-chargeback-amount | This event is used to track when a dispute is won by the cardholder and the card issuer is liable for the transaction. This could occur for several reasons, including point-of-sale conditions. This event means that the disputed amount was reclaimed from the merchant and given to the card issuer/lender. The merchant takes a loss in this scenario. |
dispute-chargeback-reversal | -dispute-chargeback-amount | This event is used to track when a dispute that was won has been fought by the merchant and funds returned to the merchant. This could occur after merchant "resentment" or "arbitration" has occurred and it has been determined that funds that were charged back will be sent to the merchant. This could occur for several reasons including point of sale conditions. In this case, the customer ends up paying for the transaction or the lender takes the loss. |
miscellaneous-issuer | none | This event is meant to record events that come from issuing processors that have not been accounted for in LoanPro. This will not happen often, if ever. However, this event allows a lender to see if something occurred on a swipe that LoanPro could not read or has not been mapped. |
Updated 10 days ago