Swipe event enumeration

Event Type	Adds To / Subtracts From	Description + Use Case
`authorization`	authorized-amount +	This event is typically 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 tagging a swipe as a `preauthorization` swipe. Typically, this event is then followed up by an `authorization-advice` event that updates the `authorized-amount` to the actual authorized amount. This event will typically 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 typically 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 should be flagged as `authorization-advice` when it's created by setting the `authorization-advice` flag to "true". This event will typically be used for something like updating the authorized amount of an 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 it 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 typically 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 event will only rarely be created on an existing swipe.
`clearing`	cleared-amount +	This event typically follows the `authorization` type event. This event is sent when a merchant actually clears the funds requested by one of the authorization events—money actually 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 any authorization first. Typically, the event should only be created when a swipe has its `force-clearing` flag set to "true". The `force-clearing` flag should 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 typically follows the `credit-authorization` type event. This event is used when a merchant clears the funds requested by one of the `credit-authorization` events and funds are moved from the merchant acquirer's account to the card issuer's account.
`credit-clearing-reversal`	credit-cleared-amount -	This event is used to update an SMA swipe that was authorized by Secure Payments but later declined by either the issuing processor or the merchant acquirer for any reason. Once notified of the decline, Secure Payments uses `void` and `credit-clearing-reversal` events to nullify the `credit-authorization` and `credit-clearing` events from the swipe. This occurs because Secure Payments approved the credit authorization that was previously requested. Once complete, this event will subtract from the cleared credit amount of a swipe.
`credit-forced-clearing`	credit-cleared-amount +	This event is used to show that a merchant credited a card without requesting any credit authorization first. Typically, this event should only 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 Secure Payments receives a `credit-clearing` event from the issuing processor with no prior `credit-authorization` event to link it to. The issuing processor may also flag swipes in this way.
`void`	voided-amount +	This event is used to free up an outstanding authorized amount on a swipe. Outstanding authorized amount = 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 event 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 never cleared or voided by the merchant.
`automatic-authorization-expired`	voided-amount +	This event is very similar to the `authorization-expired` event; 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)) ≠ 0. The automatic swipe expiration days setting is found in the card program settings and is set when a card program 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 is created for. This event should 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 reallocate an outstanding credit authorized amount on a swipe. Outstanding authorized credit amount = authorized-credit-amount - (credit-cleared-amount + voided-credit-amount). A merchant might use this event if a `credit-authorization` event is requested but then cannot be completed for some reason—meaning funds were authorized for a credit, but the credit never cleared.
`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 a provisional credit has been denied—meaning the transaction was proven to be legitimate and the cardholder lost the dispute. This event will nullify the effects of a `dispute-requested` and/or `dispute-provisional-credit` event if created on a swipe. This event should only be added to a swipe if no `dispute-write-off` or `dispute-chargeback` event exists on the swipe.
`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 should 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. After this event has been created on a swipe, no future dispute-related events should be added to the swipe.
`dispute-chargeback`	dispute-chargeback-amount +	This event is used to track when a dispute is won by the cardholder and the merchant 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. If the merchant decides to fight the chargeback decision and wins (known as "representment"), a `dispute-chargeback-reversal` event would be created to reverse the chargeback that was issued by the `dispute-chargeback` event. If a cardholder, lender, or issuer continues to pursue a chargeback after representment has occurred and wins the funds back (known as "pre-arbitration"), this event would be created to again reclaim the disputed funds from the merchant.
`dispute-chargeback-reversal`	dispute-chargeback-amount -	This event is used to track when a dispute that was previously won and charged back to the cardholder, lender, or issuer is later fought and won by the merchant—meaning the chargeback is then reversed and funds are sent back to the merchant. The cardholder takes a loss if the lender or the issuer does not forgive the cardholder of the funds during a `dispute-write-off` event. This event will be created to depict that either representment was won by the merchant or a decision was made during network arbitration in favor of the merchant.