Swipe flag scenarios
Learn how to use LoanPro’s swipe flags to handle various transaction authorization scenarios.
Swipe flags are attributes that characterize a transaction within LoanPro and determine which actions should occur.
Transaction information is passed to LoanPro’s system via the "Create swipe" request. Each transaction is characterized by seven possible Boolean attributes within the payload of this request, and these attributes determine how a transaction is handled by LoanPro—including how transaction amounts are logged and updated.
LoanPro uses the following seven flags to characterize a transaction:
issuer-declineauthorization-advicepreauthorizationforce-clearingcash-advancecredit-authorizationsma
These flags can be used singularly or in combination to handle various types of transaction scenarios. Some transaction scenarios require only one swipe flag, while others require two or even three. Use the scenario descriptions to determine which combination of swipe flags most accurately describes the transaction scenario received from your integrated issuing processor.
Scenario #1
This scenario is used when a transaction authorization request is made with a Dual Message System (DMS). If the authorization request is DMS, it should be indicated within the request for authorization.
This type of authorization request typically occurs when a transaction is either categorized as an online purchase or ecommerce. However, this is not always the case; for example, Point of Sale (POS) transactions at a payment terminal may also be DMS transactions. This type of authorization request may also be referred to as a "card not present" authorization request.
In this case, the swipe would be created and all authorization checks would occur. An authorization type swipe event would be the first and only event automatically created on the swipe. The event would show the result of the authorization checks.
Authorization checks for each flag in this scenario:
- Card status is active
- Available balance is sufficient
- Swipe restrictions do not apply
- Spend limit is not exceeded
| Flag | Value | Swipe Event(s) | Swipe Event Result (if all authorization checks are passed) |
|---|---|---|---|
| issuer-decline | false | authorization | Authorized Amount = {{authorized amount of the swipe}} |
| authorization-advice | false | ||
| preauthorization | false | ||
| force-clearing | false | ||
| cash-advance | false | ||
| credit-authorization | false | ||
| sma | false |
Scenario #2
The intention of this flag is to log a declined swipe for a dual message system (DMS) authorization request that was declined by the card's issuing processor before reaching LoanPro to be authorized.
In this case, the swipe would be created and no authorization checks would occur because the issuer-decline flag is set to true, and a normal authorization type swipe event would be the first event created on the swipe for the amount that was specified as the swipe amount.
The authorization type swipe event will be marked as "Declined: Issuer Decline" and no funds will be authorized.
There are no authorization checks in this scenario.
| Flag | Value | Swipe Event(s) | Swipe Event Result (if all authorization checks are passed) |
|---|---|---|---|
| issuer-decline | true | authorization | Declined: Issuer Decline |
| authorization-advice | false | ||
| preauthorization | false | ||
| force-clearing | false | ||
| cash-advance | false | ||
| credit-authorization | false | ||
| sma | false |
Scenario #3
The intention of this flag is to log an authorized swipe for DMS authorization requests that have been authorized by Stand-In Processing (STIP) from the network or issuing processor of the card on LoanPro's behalf.
LoanPro will receive "advice to inform" for the authorized transaction, and it cannot be declined because it has already been approved by the network or issuing processor.
In this case, the swipe would be created and no authorization checks would occur because the authorization-advice flag is set to true, and an authorization-advice type swipe event would be the first event created on the swipe for the amount that was specified as the swipe amount.
The authorization-advice type swipe event amount is set as the Authorized Amount of the swipe.
There are no authorization checks in this scenario.
| Flag | Value | Swipe Event(s) | Swipe Event Result (if all authorization checks are passed) |
|---|---|---|---|
| issuer-decline | false | authorization-advice | Authorized Amount = {{authorized amount of the swipe}} |
| authorization-advice | true | ||
| preauthorization | false | ||
| force-clearing | false | ||
| cash-advance | false | ||
| credit-authorization | false | ||
| sma | false |
Scenario #4
This flag should be used when a request for authorization is an estimate or max amount to be authorized.
These types of authorizations typically expire quicker than others and are usually followed up with an authorization-advice type swipe event to update the Authorized Amount of the swipe to the actual amount requested by the merchant.
In this case, the swipe would be created and all authorization checks would run. A preauthorization type swipe event would be the first event created on the swipe and it would show the result of the authorization checks.
Authorization checks for each flag in this scenario:
- Card status is active
- Available balance is sufficient
- Swipe restrictions do not apply
- Spend limit is not exceeded
| Flag | Value | Swipe Event(s) | Swipe Event Result (if all authorization checks are passed) |
|---|---|---|---|
| issuer-decline | false | preauthorization | Authorized Amount = {{authorized amount of the swipe}} |
| authorization-advice | false | ||
| preauthorization | true | ||
| force-clearing | false | ||
| cash-advance | false | ||
| credit-authorization | false | ||
| sma | false |
Scenario #5
This flag should be used when a clearing message has been received with no prior authorization being requested for the transaction.
This is bad practice by the payment processor of the merchant and should not commonly occur, but it is a possibility that should be accounted for. Most issuing processors will mark a transaction as a "forced post" or something similar to indicate that the funds were not authorized but are now being cleared.
In this case, the swipe would be created and no authorization checks would occur because the force-clearing flag is set to true. A forced-clearing type swipe event would be the first event created on the swipe to indicate that this swipe was cleared without any prior authorization being requested.
There are no authorization checks in this scenario.
| Flag | Value | Swipe Event(s) | Swipe Event Result (if all authorization checks are passed) |
|---|---|---|---|
| issuer-decline | false | forced-clearing | Cleared Amount = {{cleared amount of the swipe}} |
| authorization-advice | false | ||
| preauthorization | false | ||
| force-clearing | true | ||
| cash-advance | false | ||
| credit-authorization | false | ||
| sma | false |
Scenario #6
This flag should rarely if ever be set to TRUE by itself. Usually, this flag will be checked along with the SMA flag because money is being authorized and cleared at the same time during most cash advance transactions.
In this case, the swipe would be created and authorization checks would occur—taking into account the cash-advance flag being set to true—meaning that the available advance balance of the card would be used instead of the available balance to verify the availability of funds for the transaction. An authorization type swipe event would be the first event created on the swipe, and it would show the result of the authorization checks.
Authorization checks for each flag in this scenario:
- Card status is active
- Available advance balance is sufficient
- Swipe restrictions do not apply
- Spend limit is not exceeded
| Flag | Value | Swipe Event(s) | Swipe Event Result (if all authorization checks are passed) |
|---|---|---|---|
| issuer-decline | false | authorization | Authorized Amount = {{authorized amount of the swipe}} |
| authorization-advice | false | ||
| preauthorization | false | ||
| force-clearing | false | ||
| cash-advance | true | ||
| credit-authorization | false | ||
| sma | false |
Scenario #7
This flag will be used to indicate that money is being authorized to be given as a credit on the card through a DMS credit authorization.
A use case for this scenario could involve a cardholder returning an item to a merchant. The merchant would then return the funds used to purchase the item back to the cardholder as a credit on the card. A clearing message will later be received to indicate that the credit has cleared for which a Clearing type swipe event should be created.
In this case, the swipe would be created and the only authorization check that would occur on the card would be to verify that the card is in the "Active" status. A credit-authorization type swipe event would be the first event created on the swipe and it would show the result of the credit authorization check for card status.
Authorization checks for each flag in this scenario:
- Card status is active
| Flag | Value | Swipe Event(s) | Swipe Event Result (if all authorization checks are passed) |
|---|---|---|---|
| issuer-decline | false | credit-authorization | Authorized Credit Amount = {{authorized credit amount of the swipe}} |
| authorization-advice | false | ||
| preauthorization | false | ||
| force-clearing | false | ||
| cash-advance | false | ||
| credit-authorization | true | ||
| sma | false |
Scenario #8
This flag will be used when a transaction is requested to be authorized with a Single Message System (SMS). If the authorization request is SMS, it should be indicated within the request for authorization.
This type of authorization request will typically occur when a transaction is considered Point-of-Sale (POS) and is made at a payment terminal. This type of authorization request could also be referred to as a "Full Financial" authorization request.
In this case, the swipe would be created and all authorization checks would occur. An authorization type swipe event would be the first event created on the swipe, and it would show the result of the authorization checks. If the swipe was approved by the authorization checks, then LoanPro will automatically add a clearing type swipe event to the swipe for the amount that was authorized.
Authorization checks for each flag in this scenario:
- Card status is active
- Available advance balance is sufficient
- Swipe restrictions do not apply
- Spend limit is not exceeded
| Flag | Value | Swipe Event(s) | Swipe Event Result (if all authorization checks are passed) |
|---|---|---|---|
| issuer-decline | false | authorization | Authorized Amount = {{authorized amount of the swipe}} |
| authorization-advice | false | clearing | Cleared Amount = {{cleared amount of the swipe}} |
| preauthorization | false | ||
| force-clearing | false | ||
| cash-advance | false | ||
| credit-authorization | false | ||
| sma | true |
Scenario #9
The intention of this flag set is to log a declined swipe for DMS preauthorization requests that were declined by the issuing processor of the card before ever reaching LoanPro to be authorized.
In this case, the swipe would be created, no authorization checks would occur due to the issuer-decline flag being set to true, and a preauthorization type swipe event would be the first event created on the swipe. The preauthorization type swipe event will be marked as "Declined: Issuer Decline" and no funds will be authorized.
There are no authorization checks in this scenario.
| Flag | Value | Swipe Event(s) | Swipe Event Result (if all authorization checks are passed) |
|---|---|---|---|
| issuer-decline | true | preauthorization | Declined: Issuer Decline |
| authorization-advice | false | ||
| preauthorization | true | ||
| force-clearing | false | ||
| cash-advance | false | ||
| credit-authorization | false | ||
| sma | false |
Scenario #10
The intention of this flag set is to log a declined swipe for DMS cash advance authorization requests that were declined by the issuing processor of the card before ever reaching LoanPro to be authorized.
In this case, the swipe would be created, no authorization checks would occur due to the issuer-decline flag being set to true, and a normal authorization type swipe event would be the first event created on the swipe. The authorization type swipe event will be marked as "Declined: Issuer Decline" and no funds will be authorized.
There are no authorization checks in this scenario.
| Flag | Value | Swipe Event(s) | Swipe Event Result (if all authorization checks are passed) |
|---|---|---|---|
| issuer-decline | true | authorization | Declined: Issuer Decline |
| authorization-advice | false | ||
| preauthorization | false | ||
| force-clearing | false | ||
| cash-advance | true | ||
| credit-authorization | false | ||
| sma | false |
Scenario #11
The intention of this flag set is to log a declined swipe for SMS authorization requests that were declined by the issuing processor of the card before ever reaching LoanPro to be authorized.
In this case, the swipe would be created, no authorization checks would occur due to the issuer-decline flag being set to true, and a normal authorization type swipe event would be the first event created on the swipe. The issuer-decline flag overrides the sma flag regarding which swipe events will be added to the swipe when it is created.
There are no authorization checks in this scenario.
| Flag | Value | Swipe Event(s) | Swipe Event Result (if all authorization checks are passed) |
|---|---|---|---|
| issuer-decline | true | authorization | Declined: Issuer Decline |
| authorization-advice | false | ||
| preauthorization | false | ||
| force-clearing | false | ||
| cash-advance | false | ||
| credit-authorization | false | ||
| sma | true |
Scenario #12
The intention of this flag set is to log an authorized swipe for DMS cash advance requests that have been authorized by STIP from the network or issuing processor on LoanPro's behalf.
LoanPro will receive "advice to inform" for the authorized transaction, and it cannot be declined because it has already been approved by the network or issuing processor.
In this case, the swipe would be created, no authorization checks would occur due to the authorization-advice flag being set to true, and an authorization-advice type swipe event would be the first event created on the swipe.
There are no authorization checks in this scenario.
| Flag | Value | Swipe Event(s) | Swipe Event Result (if all authorization checks are passed) |
|---|---|---|---|
| issuer-decline | false | authorization-advice | Authorized Amount = {{authorized amount of the swipe}} |
| authorization-advice | true | ||
| preauthorization | false | ||
| force-clearing | false | ||
| cash-advance | true | ||
| credit-authorization | false | ||
| sma | false |
Scenario #13
The intention of this flag set is to log an authorized swipe for DMS cash advance requests that have been authorized by STIP from the network or issuing processor on LoanPro's behalf.
LoanPro will receive "advice to inform" for the authorized transaction, and it cannot be declined because it has already been approved by the network or issuing processor.
In this case, the swipe would be created, no authorization checks would occur due to the authorization-advice flag being set to true, and an authorization-advice type swipe event would be the first event created on the swipe.
There are no authorization checks in this scenario.
| Flag | Value | Swipe Event(s) | Swipe Event Result (if all authorization checks are passed) |
|---|---|---|---|
| issuer-decline | false | authorization-advice | Authorized Amount = {{authorized amount of the swipe}} |
| authorization-advice | true | clearing | Cleared Amount = {{cleared amount of the swipe}} |
| preauthorization | false | ||
| force-clearing | false | ||
| cash-advance | false | ||
| credit-authorization | false | ||
| sma | true |
Scenario #14
The intention of this flag set is to log an authorized credit for DMS credit authorization requests that have been authorized by STIP from the network or issuing processor of the card on LoanPro's behalf.
LoanPro will receive "advice to inform" for the authorized credit, and it cannot be declined because it has already been approved by the network or issuing processor. A clearing message will be sent to clear the credit that has been authorized.
In this case, no authorization checks would occur. A credit-authorization type swipe event would be the first event created on the swipe. The credit-authorization event should have a result of "Approved Authorization Advice, Authorized Credit Amount = [authorized credit amount of the swipe]".
There are no authorization checks in this scenario.
| Flag | Value | Swipe Event(s) | Swipe Event Result (if all authorization checks are passed) |
|---|---|---|---|
| issuer-decline | false | credit-authorization | Approved Authorization Advice, Authorized Credit Amount = {{authorized credit amount of the swipe}} |
| authorization-advice | true | ||
| preauthorization | false | ||
| force-clearing | false | ||
| cash-advance | false | ||
| credit-authorization | true | ||
| sma | false |
Scenario #15
The intention of this flag set is to authorize a swipe for DMS preauthorization cash advance requests.
This scenario should nearly never occur because a preauthorization request usually indicates that the requested amount is an estimated purchase price. The requested amount should never be an estimate in the case of a cash advance. However, the tools here account for the scenario if it were to arise.
In this case, the swipe would be created, authorization checks would occur while acknowledging the cash-advance flag being set to true. A preauthorization type swipe event would be the first event created on the swipe, and it would show the result of the authorization checks.
Authorization checks for each flag in this scenario:
- Card status is active
- Available balance is sufficient
- Swipe restrictions do not apply
- Spend limit is not exceeded
| Flag | Value | Swipe Event(s) | Swipe Event Result (if all authorization checks are passed) |
|---|---|---|---|
| issuer-decline | false | preauthorization | Authorized Amount = {{authorized amount of the swipe}} |
| authorization-advice | false | ||
| preauthorization | true | ||
| force-clearing | false | ||
| cash-advance | true | ||
| credit-authorization | false | ||
| sma | false |
Scenario #16
This flag set should be used when a clearing message has been received with no prior authorization request for the transaction in addition to the clearing message having been marked as a cash advance.
This is bad practice by the payment processor of the merchant and should not commonly occur; but it is a possibility that should be accounted for. Most issuing processors will mark a transaction as a "forced post" or something similar to indicate that the funds were not authorized but are now being cleared.
In this case, the swipe would be created, no authorization checks would occur due to the force-clearing flag being set to true, and a forced-clearing type swipe event would be the first event created on the swipe. The cash-advance flag does not matter because no authorization checks were run on the swipe. However, it will likely matter for interest calculation depending on how the card has been set up.
There are no authorization checks in this scenario.
| Flag | Value | Swipe Event(s) | Swipe Event Result (if all authorization checks are passed) |
|---|---|---|---|
| issuer-decline | false | forced-clearing | Cleared Amount = {{cleared amount of the swipe}} |
| authorization-advice | false | ||
| preauthorization | false | ||
| force-clearing | true | ||
| cash-advance | true | ||
| credit-authorization | false | ||
| sma | false |
Scenario #17
This flag should be used when a clearing message has been received with no prior authorization request for the transaction in addition to the transaction being a credit to the cardholder.
Most issuing processors will mark a transaction as a "forced post" or something similar to indicate that the funds were not authorized but they are now being cleared to be returned to the card.
In this case, no authorization checks occur on the swipe. A credit-authorization type swipe event would be the first event created on the swipe. The credit-authorization event should have a result of "Approved Forced Clearing, Authorized Credit Amount [Amount of the swipe]" then a forced-clearing type swipe event would automatically be added to the swipe for the amount that was specified in the swipe.
There are no authorization checks in this scenario.
| Flag | Value | Swipe Event(s) | Swipe Event Result (if all authorization checks are passed) |
|---|---|---|---|
| issuer-decline | false | credit-authorization | Approved Authorization Advice, Authorized Credit Amount = {{authorized credit amount of the swipe}} |
| authorization-advice | false | forced-clearing | Cleared Amount = {{cleared amount of the swipe}} |
| preauthorization | false | ||
| force-clearing | true | ||
| cash-advance | false | ||
| credit-authorization | true | ||
| sma | false |
Scenario #18
The intention of this flag set is to authorize an SMS cash advance authorization request. If the authorization request is SMS, it should be indicated within the request for authorization.
This type of authorization request (SMS) should be the most commonly used for cash advance authorization requests. This type of authorization request may also be referred to as a "Full Financial" cash advance authorization request.
In this case, the swipe would be created, authorization checks would occur while acknowledging the cash-advance flag being set to true. An authorization type swipe event would be the first event created on the swipe, and it would show the result of the authorization checks. If the swipe was approved by the authorization check, then a clearing type swipe event would automatically be added to the swipe by LoanPro for the amount that was authorized.
Authorization checks for each flag in this scenario:
- Card status is active
- Available balance is sufficient
- Swipe restrictions do not apply
- Spend limit is not exceeded
| Flag | Value | Swipe Event(s) | Swipe Event Result (if all authorization checks are passed) |
|---|---|---|---|
| issuer-decline | false | authorization | Authorized Amount = {{authorized amount of the swipe}} |
| authorization-advice | false | clearing | Cleared Amount = {{cleared amount of the swipe}} |
| preauthorization | false | ||
| force-clearing | false | ||
| cash-advance | true | ||
| credit-authorization | false | ||
| sma | true |
Scenario #19
This flag set will be used to indicate that funds are being authorized to be given as a credit on the card through an SMS credit authorization.
A use case for this scenario could involve a cardholder returning an item to a merchant. The merchant would then return the funds used to purchase the item back to the cardholder as a credit on the card. A clearing message will not be received to indicate that the credit has cleared because the credit authorization message is an SMS.
In this case, the swipe would be created, authorization checks would occur to ensure the card exists and is in the "Active" status. A credit-authorization type swipe event would be the first event created on the swipe. If the return was approved by the card status check, then a clearing type swipe event would automatically be added to the swipe by LoanPro for the amount that was authorized because sma is set to true.
Authorization checks for each flag in this scenario:
- Card status is active
| Flag | Value | Swipe Event(s) | Swipe Event Result (if all authorization checks are passed) |
|---|---|---|---|
| issuer-decline | false | credit-authorization | Authorized Credit Amount = {{authorized credit amount of the swipe}} |
| authorization-advice | false | clearing | Cleared Amount = {{cleared amount of the swipe}} |
| preauthorization | false | ||
| force-clearing | false | ||
| cash-advance | false | ||
| credit-authorization | true | ||
| sma | true |
Scenario #20
The intention of this flag set is to log a declined swipe for DMS preauthorization cash advance requests that were declined by the issuing processor of the card before ever reaching LoanPro to be authorized.
This scenario should nearly never occur because a preauthorization request usually indicates that the requested amount is an estimated purchase price. The requested amount should never be an estimate in the case of a cash advance. However, the tools here account for the scenario if it were to arise.
In this case, the swipe would be created, no authorization checks would occur due to the issuer-decline flag being set to true, and a preauthorization type swipe event would be the first event created on the swipe. The Preauthorization type swipe event will be marked as "Declined: Issuer Decline" and no funds will be authorized.
There are no authorization checks in this scenario.
| Flag | Value | Swipe Event(s) | Swipe Event Result (if all authorization checks are passed) |
|---|---|---|---|
| issuer-decline | true | preauthorization | Declined: Issuer Decline |
| authorization-advice | false | ||
| preauthorization | true | ||
| force-clearing | false | ||
| cash-advance | true | ||
| credit-authorization | false | ||
| sma | false |
Scenario #21
The intention of this flag set is to log a declined swipe for SMS cash advance authorization requests that were declined by the issuing processor of the card before ever reaching LoanPro to be authorized.
This is the most likely scenario to occur if a cash advance authorization request is declined by STIP.
In this case, the swipe would be created, no authorization checks would occur due to the issuer-decline flag being set to true, and a normal authorization type swipe event would be the first event created on the swipe. The authorization type swipe event will be marked as "Declined: Issuer Decline" and no funds will be authorized.
There are no authorization checks in this scenario.
| Flag | Value | Swipe Event(s) | Swipe Event Result (if all authorization checks are passed) |
|---|---|---|---|
| issuer-decline | true | authorization | Declined: Issuer Decline |
| authorization-advice | false | ||
| preauthorization | false | ||
| force-clearing | false | ||
| cash-advance | true | ||
| credit-authorization | false | ||
| sma | true |
Scenario #22
The intention of this flag set is to log an authorized swipe for SMS cash advance authorization requests that have been authorized by STIP from the network or issuing processor of the card on LoanPro's behalf.
LoanPro will receive "advice to inform" for the authorized transaction, and it cannot be declined because it has already been approved by the network or issuing processor.
In this case, the swipe would be created, no authorization checks would occur due to the authorization-advice flag being set to true, and an authorization-advice type swipe event would be the first event created on the swipe, followed by a clearing type swipe event for the amount of the authorization-advice due to sma being set to true. The cash-advance flag does not matter for authorization because no authorization checks occur on the swipe. However, it will likely matter for interest calculation depending on how the card has been set up.
There are no authorization checks in this scenario.
| Flag | Value | Swipe Event(s) | Swipe Event Result (if all authorization checks are passed) |
|---|---|---|---|
| issuer-decline | false | authorization-advice | Authorized amount = {{authorized amount of the swipe}} |
| authorization-advice | true | clearing | Cleared amount = {{cleared amount of the swipe}} |
| preauthorization | false | ||
| force-clearing | false | ||
| cash-advance | true | ||
| credit-authorization | false | ||
| sma | true |
Scenario #23
The intention of this flag set is to log an authorized credit for SMS credit authorization requests that have been authorized by STIP from the network or issuing processor of the card on LoanPro's behalf.
LoanPro will receive advice to inform of the authorized credit, and it cannot be declined because it has already been approved by the network or issuing processor. A clearing message will not be received to indicate that the credit has cleared because the credit authorization message is an SMS.
In this case, the swipe would be created, and no authorization checks would occur. A credit-authorization type swipe event would be the first event created on the swipe. Then a clearing type swipe event would automatically be added to the swipe by LoanPro for the amount that was authorized due to sma being set to true. The credit-authorization event that is created should have a result of "Approved Authorization Advice, Authorized Credit Amount = {{authorized credit amount of the swipe}}".
There are no authorization checks in this scenario.
| Flag | Value | Swipe Event(s) | Swipe Event Result (if all authorization checks are passed) |
|---|---|---|---|
| issuer-decline | false | credit-authorization | Approved Authorization Advice, Authorized Credit Amount = {{authorized credit amount of the swipe}} |
| authorization-advice | true | clearing | Cleared amount = {{cleared amount of the swipe}} |
| preauthorization | false | ||
| force-clearing | false | ||
| cash-advance | false | ||
| credit-authorization | true | ||
| sma | true |
Updated 22 days ago