Setting up Authorize.net

 Following bullets explain how to start authorize.net for a customer:

1. To turn on set vcValue1 and vcValue2 for SliperCSV SoftSet with api-login-id and transaction-key respectively. If SlipverCSV setting exists and both vcValue1 and vcValue2 has value then authorize.net is considered setup.
2. Authorize.net may or may not support multiple currencies. Following setting is required to setup supporting currencies:
   1. The SoftSet MultiCurrencySupported: vcValue1 equals true means authorize.net supports both currencies. In this case system ignores settings in vcValue2. If vcValue1 equals false, then authoize.net supports only one currency that is mentioned in vcValue2.
3. Because wallet system uses alert and deactivation thresholds, so overall contract limit must be configured for authorize.net. For this changes settings in EnableOverallLimit SoftSet as we do while turning on overall limit. If regular overall limit control is not required then keep EnableOverallLimit setting disabled by setting vcValue1 to false. While monitoring wallet balance system considers values from vcValue2 and vcValue3. vcValue2  contains alert threshold and vcValue3 contains deactivation threshold.
4. Authorize.net has some filters to prevent fraud. Two of them are lower limit and upper limit. This means if transaction amount falls below lower-limit and goes above upper-limit, then authorize.net isolates such transactions for user review. We have one settings to keep these thresholds in our system so that user could be alerted in advance if a transaction does not fall between lower and upper limits. Set SliperAccountLimit SoftSet with vcValue1 as lower limit, vcValue2 as upper limit.
5. If payment process at authorize.npet is TSYS, then this means primary client can charge credit card fee from the customer. In this case software send surcharge in a special field, if TSYS is not supported then fundamentally primary client cannot charge credit-card-fee from its customer. But still we gave a provision that is, we send surcharge as a merchandize item, but with this primary client does not save its credit card fee.  To enable surcharge vcValue1 for the SoftSet PaymentSurcharge should be true and vcValue2 should be true if TSYS is supported else it should be false. If this setting is true then software pick surcharge fee from CreditSurchargeMaster table. 
6. CreditSurchargeMaster table must have valid surcharge fee for all types of credit cards including one mandatory entry for "Unknown" type. If customer uses a card that does not exist in CreditSurchargeMaster table then surcharge from "Unknown" will be applied.

Once aforementioned setup is complete, define user rights for other users to that they can open Mange Payment Profile page. For this open user manager from SwissFuel and grant Manage Payment rights to the concerned users. All super admins will be auto-authorized to manage payments. Other admins and users would require super-admin to grant rights for them. 

What is changed?

Earlier software did not have any system to keep payment history. The only thing that it could do was flagging an invoice as paid, so earlier either invoice could be paid or unpaid. following bullets list changes:

1. now software will expect the actual amount that has been received from the secondary client.
2. With current system invoice can have three states i.e. paid, unpaid or partially paid.
3. Now invoices would be settled in FIFO order. this means payment is not received against a particular invoice number. If secondary client has 2 unpaid invoices, then pay now window will show total due amount equal to the total amount of both invoices. backend system auto adjust this amount in FIFO order. It will settled the oldest pending invoice first, then newer and then the newest invoice will be settled.
4. Now a customer can be prepaid or postpaid. In case customer is prepaid, then its wallet will be turned on automatically. This means secondary client will now load money in the wallet and can consume only that much that it has in its wallet.
5. overall limit calculations have been adjusted according to new changes. "bitConsiderPaidInvoices" setting has been depcrecated now. now the real invoice balance will be considered as used limit. If customer type is prepaid, then its overall limit system will be auto enabled, irrespective of any setting at global level or at customer level. If customer is prepaid then overall limit system will be enforced.
6. for prepaid customers. overall limit will be equal to the total amount in wallet. If user has both CAD and USD amount in wallet, then CAD amount will be converted to USD and then total amount of both will be considered as overall limit. Overall limit field in edit customer will be overridden by this value.
7. Special Attention for Prepaid Setting: Until a customer is not flagged as prepaid, it does not have option to add funds. If the customer already have some transactions, then as soon as prepaid check box is checked, its wallet balance will be negative and its cards will be deactivated. To avoid this an option for initial deposit has been added. To avoid unexpected deactivation of cards, primary client must add initial deposit. Initial deposit is the amount that is added after adjusting previous transactions, plus 15% of the minimum initial deposit setting in SoftSets. The correct way is that primary client should generate invoices for all previous pending transactions and receive payment so that the balance of secondary client is zero. Otherwise, while setting a customer as prepaid, initial deposit can be Total Balance Amount + Initial Deposit + 15% of initial deposit. For example, if customer already have $5000 balance, and primary client wants add $2000 as initial deposit, $7300 (5000+2000 + (2000*15%)) should be added in the wallet while setting up prepaid customer.
   Minimum Initial Deposit: A soft set defines initial deposit (USD) per card. For example if a customer has 50 cards and per card initial deposit is $200 (USD), then minimum initial deposit will be 200 * 50 = 10,000 US$. Assuming all 50 trucks will not be fueling at a time, per card initial deposit can be adjusted. For example if on average 25 out of 50 trucks buy fuel daily, then per card initial deposit can be 50 * (one time average fuel capacity of a truck / 2).
   But there is a hard coded setting for a minimum amount of $1000. If no soft set defined for minimum initial deposit or amount defined in the setting is less than 1000, then this setting takes place. This means a customer can never add initial deposit below $1000. This was done so that a customer is not unexpectedly deactivated once it is switched as prepaid customer.
    Why is 15% added? Consider this example. Assume a customer has unpaid transactions equal to $2000. The primary client adds $2800 (2000 + 800 initial deposit). This will make wallet balance to $800, which is barely enough for one truck. In SoftSets, deactivation threshold is 90% of available limit which is $800 in this case. As soon a driver of the customer fuels a truck, then it will hit deactivation threshold and customer and its all cards will be deactivated. So if a customer wants to add $800 as initial deposit then 800 + 15 percent (100 - 90  +5) should be added, so that if customer fuels one truck full, then it should get deactivation alert instead of getting deactivated all of a sudden. 5% additional is added so that the usage could not hit 90% instantly. So, the number 15% can be any number that calculates to (100 - deactivation_threshold + 5). 15 is used as example because in most cases deactivation threshold is 90%.
   Exception: A customer can still get deactivated all of a sudden despite of these arrangements. $800 in above example is the most precise estimate of customer's average use by the primary client. If a customer starts fueling two trucks simultaneously, then it will never get an deactivation alert, but the customer will be deactivated all of a sudden.
   Total Initial Deposit Currency: Final total initial deposit that is considered for calculations is always in USD. This is because overall limit monitoring system converts all numbers to USD before deciding about deactivation or alerts. So all calculations described above are on final total that is in US$. 
   Initial Credit in Both Currencies: Irrespective of any setting i.e. MultiCurrency for authorize.net or other payment system. This is part of wallet reload system, postponed for now, but will be coming soon. In case automated payment system does not have option for a currency, assume USD, then the primary client can have manual arrangements of getting payment in advance then manually adding into the wallet. This will also help when prepaid system will be turned on without any automated payment system. In this case the primary client can get a lumpsum payment in advance that will be settled in both CAD and USD invoices.
   
   
8. When EFT is generated, then in case of multiple invoices Pay Invoice window will show first invoice only.  This is because payment will be received against first invoice and excess payment will be adjusted in following invoices in FIFO order. First invoice is picked for FIFO concept, because whenever payment is received, then first ever unpaid invoice must be paid first. When eft file is generated then in case of multiple invoices eft file will add asterisks (stars) after invoices. 

Update:

• Softset added for minimum Wallet balance WalletMinimumBalance. The vcValue1 in this softset will replace the hardcoded $1000 minimum deposit. The vcValue2 in the softset will have the minimum recomended balance for each card. so the recomended wallet balance for the customer with atleast one card would be (number of cards * vcValue2  * 1.15 )
•  If WalletMinimumBalance setting is missing or Zero, then system enforces hard coded $1000 as minimum deposit. If user wants to set 0 as minimum balance then it must set it as any number greater than zero e.g. 0.01. User can change this setting itself in System Settings page.

Changes in Pay invoice window:

1. User can use any of following payment methods to receive payment: ACI, Authorize.net , manual and eft etc.
2. Payment via eft is same as manual payment because in case of eft user downloads eft and sends to bank. so we have no way to cross verify payment processing. In this case user will manually enter amount received. This also means that if we do not have a system to cross verify receipts, then invoice settlement will be equal to manual mode.
3. Filters in pay invoice window are changed as described below:
   • Customers with a valid payment method: if a customer has been setup for authorize.net .
   • Customers ready for EFT/ACH: if a customer has EFT/ACH on. If an customer has both authorize.net and EFT then it will appear in both filters.
   • Other Customers: Who does not fall in any of the above categories.
   • Currency: The currency dropdown filer will be affected by the Customer type selected value. It will remain same for the following customer types: Customers ready for EFT/ACH and Other Customers. But when Customers with valid payment method customer type is selected, options for this dropdown will be loaded as per "MultiCurrencySupported" SoftSet, this is the soft set that tells which currency is accepted by authorize.NET .
   • Invoice type: This filter is only available when Customers with valid payment method customer type is selected, it has 2 options: Unpaid, and In process. When selected UNPAID, the grid will show a list of customers with unpaid invoices. For IN PROCESS, the grid will show a list of customers who have any pending payments (payments that have not been settled on authorize.NET ).
4.  Pay now button will be visible in all cases even in case of EFT and ACH. Generating EFT/ACH file does not mean that invoice has been paid. After downloading EFT/ACH files, they will be uploaded in bank's portal. Then the bank will take some time to process. Once the primary user has payment status of all transactions in the EFT/ACH file, then it will verify every invoice in the Pay Now window and will process invoice payment. So Pay Now button must be visible in case of "Customers ready with EFT/ACH" filter also.

Filters cannot have "All Customers" option because only one type of payment can be processed. There is a case when a customer may have both EFT enabled and a valid payment method. Such customers will appear for both filters i.e. for bullet 1 and 2 above. Assume the user selected filter 2 and there is a customer X who has both EFT and a valid payment method. So, the grid that lists customers will show customer X. If the user processes payment then this customer X will not appear for filter 1 because its invoice was processed. If the user unselects this customer before clicking the pay now button, then the list for filter 2 will include customer X.

Changes in the grid

The grid will have columns in the following order:
Customer ID | Customer Name | Invoice number(s) | Currency | Amount Due | Charged Amount.

1. Amount Due : The amount due is the sum of the invoiced amount of all unpaid invoices.
2. Charged Amount: By default, this field will be equal to Amount Due. But the user can add a number less than, equal to, or greater than the Amount Due.
3. If the customer is Prepaid, and if any of its invoices are underpaid, then this invoice will also appear in the grid. Explanation: Because the system come to know about used amount only after the transaction has happened, so secondary client may overuse its wallet. For example, if wallet balance is 300 and secondary client fuels for $350, then the invoice will have a balance of $50. Such invoices should appear highlighted in the grid.

Conditions

The pay invoice window's behavior will change according to the following conditions:

1. Customer Type filter drop-down will have options according to:
2. Option 1 if Anet is on
3. Option 2 if EFT is on
4. Option 3: In all cases.

How to Pay Now?
Users have to select customers for the payment, and modify the amount charged, as per requirement. Users can pay more/less than the suggested amount but have to fulfill charge amount validations. Click the Pay No button and follow on-screen instructions.

Charge Amount validations:
When making payments for authorize.NET customers, the charged amount has an upper limit and lower limit validation as per "SliperAccLimit" SoftSet. For all other cases, the only validation is charge amount should be greater than 0.

How payments are processed with authorize.net?

Before further reading, following section must be understood correctly to understand behavior of the system:

1. Authorize.NET does not immediately fund the transaction. Instead, it undergoes a settlement process. The transaction is sent for settlement at a cut-off time specified in Authorize.NET 's online configurator. After the settlement process, the transaction status is updated to "Settled Successfully." This indicates that the payment has been successfully processed and settled. To check the transaction status, a service will keep on running every 2 hour to check the status of all pending requests(awaiting for settlement). Once service have received "Settled Successfully" status for a transaction, that payment will be settle pending invoices for the customer for received payment. If the transaction settlement failed due to any reason, user will be notified via email. EFT/ACH or Other payment processing For all other type of payments, SettleInvoices command will be executed to settle the payment and invoice against the receipt of that payment.
2. If payment processor at authorize.net is TSYS, then setup in SwissFuel can be used to apply surcharge on credit card payments.
3. If payment processor does not supports multi currency, then setup in SwissFuel can be used process only that currency that has been setup at authorize.net . We have following settings for this setup:
   • We have a MultiCurrencySupported setting for authorize.Net . This SoftSet will have 2 values. Value 1 represents if we need to include currency in the SoftSet. Value2 Represents the current currency of the authorize.NET processor. When vcValue1 is true, then it means processor supports multi currency. If vcValue1 is false, then we can payment can be processed in the only currency specified in vcValue2.

Payment processing goes through following steps. None of the payment processing part is performed at front end. All steps are at the backend.

1. when user clicks on pay now button, then all selected invoices are enqueued for processing.
2. backend system activates within 0 to 30 seconds to process all enqueued invoices.
3. Anet transaction is created for every enqueued invoice and sent to authorize.net for processing.
4. authorize.net sends all transactions to banks for settlement at pre-specified cut-off time. Until that time invoices will be shown as in-process in pay now window. user can filter such invoices. In-process invoices cannot be used for scheduling other payments. For example if secondary client A pays 200 against an invoice of 500, then balance 300 cannot be received until system finishes enqueued processing of same invoice.
5. One hour after the cut off time backend system goes to authorize.net to check status of transactions. All transactions that are settled by authorize.net are considered as completed. For all completed transactions backend system settles invoices in FIFO order. This process is repeated after every hour, for 5 times only if pending transaction detected in the SfRequest table.
6. Once an invoice is settled, then secondary client receives a statement indicating which invoice was settled and how much amount was settled and how much is the balance
7. authorize.net has maximum transaction limit alert. in this if a transaction total goes beyond that limit then authorize.net does not process that transaction and flag it as for manual review. Primary user will get email for such transactions. In this case primary client will login to authorize.net portal and will clear those transactions. once cleared backend system will settle those transactions also.
8. if a transaction is declined then backend system will send email notification to both primary client and secondary client.

Customer Questionnaire

before start using , Authorize.NET customers will be asked for few questions regarding the setup and expected usage of the payment system.some the questions will ask about :

• Maximum amount limit for a transaction
• Minimum amount limit for a transaction
• ask if the customer wants multi currency ? we have a SoftSet for that.
• ask if the customer wants to apply surcharge in their Credit card transactions, if yes then setup soft set key for this.

How will CUT-OFF time work?

• Authorize.Net triggers cut off time once a day to push transactions for the settlement.
• But we don’t how much time bank will take to finally settle the transactions.
• So a service will run after every hour after cut-off time to check the status of all transactions which have status R in the SfRequest Table.
  • Service will start processing pending transaction 1 hour after the cut-off time. For example: cut-off time is set to 8 am, the service will make its first attempt at 9 am.
  • The service will retry 5 times to settle all pending transactions, after 5 tries it will check for pending payments in the system, remaining will be settled the next day.(The only case is when payment will remain unsettled after 5 successful tries when the payment is held for a review).
  
  Action required from customer :
• When any transaction held for review an email alert and a critical notification will be pushed to clients(to the person who will owns/manage the authorize.Net merchant account), to inform that a manual review required for specific transactions. Client can make the transaction Approve/decline with in 5 days of the actual transaction. If the client failed to review the transaction with in specified time then that specific transaction will be marked as Expired.

Declined Transaction

When a transaction declined send and email alert and a critical portal notification to the client admin as well as the card holder.

Authorize.NET effects on EFT/ACH#

• EFT and ACH are always generated for full invoice amount and cannot have partial amounts. While generating EFT primary client will never ask secondary client that how much are you paying for this invoice.  Second reason is that in case of EFT/ACH if there is an option to edit amount, then there is no way to keep record of the edited amounts. If there are customers who do not pay full invoices, then EFT/ACH options must be turned off for such customers. EFT and ACH will be generated for full amount
• Once user have generated the EFT/ACH file, only he is responsible to click on Pay Now button to settle invoices.
• For EFT/ACH invoices will be settled on click of the Pay Now button.
• Charge amount cannot be changed.