[Enterprise] Electronic Payment Processing FAQ

All Gateways

Q. How is an eCheck reject seen in netFORUM Enterprise?

A. In an eCheck (ACH) request is rejected at the point of sale when making an ACH payment, then netFORUM will show the error message received from the gateway and the transaction will halt. The operator may attempt to correct the entry in case of a typo, try the payment again, or provide a different payment method.

If the eCheck payment was made in a scheduled task that processes electronic payments in netFORUM 2015.1 or later, then an ACH decline will be logged in the gateway decline log; see Automatic Payments Overview for more. For these scenarios in netFORUM 2014.1 or earlier, the error is logged in a task history detail. The new gateway decline log in netFORUM 2015.1 provides for more sophisticated tracking and recycling for automatic payments.

Q. My organization has two business units, each with a different merchant account (MID) and different bank accounts. We would like to split one payment between the two different MIDs, rather than have all the payment go to one MID and then move the money between MIDs after the fact.

A. In netFORUM Enterprise, you can have multiple MIDs with multiple payment gateways or a single payment gateway, but each electronic payment can be directed to only one MID. In order to reconcile these payments and ensure each bank account ultimately gets the correct deposit, set up netFORUM in the following way and follow these guidelines:

Suppose you have two business units, Membership and Foundation, each with its own chart of accounts. Suppose you have a payment directed toward two line items on the same invoice: Membership for $100 and Foundation for $50. The member makes a $150 payment. Based on the payment method chosen, the payment will be processed with the MID linked to that payment method, which could be either Membership or Foundation. For this example, let's assume the payment method is linked to the Membership MID. The Membership MID will get a $150 deposit from the gateway (less any fees). In netFORUM, you should have a due-to/due-from set of accounts for the respective cash accounts for the Membership cash account and the Foundation cash account.

When you close and post the payment batch in netFORUM, a set of due-to-/due-from ledger records will be created indicating that $50 should transfer from the Membership cash account to the Foundation cash account. On a regular basis you should aggregate these (under the assumption that there will also be likely be sets of ledger records indicating a transfer in the opposite direction) in order to make a transfer payment from the Membership bank account to the Foundation bank account , or vice versa. For example, in the scenario above, you would transfer $50 from the membership bank account to the foundation bank account. But if there was another payment toward the Foundation bank account that also had a membership line item, and it was a $600 payment with $500 that should go to Membership and $100 to Foundation, then ultimately when both of these payments are reconciled, you will need to transfer $450 from Foundation to Membership.

International Currencies

Q. How are international currencies handled?

A. [Applies to Sage, Vantiv and BluePay] When you set up a merchant account in a processor, the merchant account is configured to have all incoming payment requests be in a single specific currency. When netFORUM sends a payment request to a gateway for that particular merchant account, the amount to be charged will be in the merchant account's defined currency. netFORUM does not provide a currency symbol or indicator in a payment request to a gateway, only a numeric value for the payment. If a merchant account is configured for Euros, then any payments made toward that merchant account (via netFORUM payment method being linked to netFORUM merchant account, which in turn is  linked to a netFORUM gateway) will process in Euros.

Because of this, you must ensure that your netFORUM multi-currency setup and your netFORUM payment methods and business units are all aligned to the same currency. If your merchant account is set up in Euros, but you link the associated netFORUM merchant account to a netFORUM payment method in a netFORUM business with USD currency, then when a product is purchased under that payment method for $9.88 USD, netFORUM will send "9.88" to the merchant account but the processor will charge 9.88 Euro because the merchant account is configured in Euro.

For example, if you would like to receive payments in Euros and USD, then in netFORUM you will need to setup two merchant accounts, one for Euro and the other for USD; you will also have two merchant accounts in the gateway, one for each currency, and you will link the netFORUM USD merchant account to the USD gateway merchant account, and the netFORUM Euro merchant account with the Euro gateway merchant account.  Each netFORUM merchant account will be linked to the different payment methods for credit cards and ACH. Each payment method must be setup with only one currency based on the currency setup for the corresponding merchant account.

Voiding a Payment

Q. When I void an electronic payment in netFORUM, what happens in the gateway? Does it void the gateway payment or create a credit in the gateway?

A. Beginning in netFORUM 2014.1.13 HF3, 2015.1.8 HF3, 2017.1.4 HF3​, and later versions, when you void a payment in netFORUM, then netFORUM attempts to void the gateway payment as long as you are voiding all of the payment line-items for that payment. In earlier versions of netFORUM, netFORUM instead would attempt a credit by reference (also known as a refund) to the gateway, for the amount being voided, against the original gateway transaction. For reference, this change was made in issue 20551.

Before going into more detail, first some clarification on these terms, which have slightly different meetings in netFORUM versus electronic payment gateways.

netFORUM void of payment - this means you are basically trying to "make the payment go away." In netFORUM, you can void a payment only if the payment is still in a non-closed batch. If the payment's batch has been closed, then you may perform a "void with adjustment."

Gateway void - you can void a captured/settled authorization in a gateway, either in the merchant portal (not recommended) or by performing a certain operation in the AMS, as long as the settlement hasn't been fully deposited yet.

netFORUM credit - netFORUM issues credits for various reasons. For example, if in netFORUM you void a payment, you can choose "void" (meaning "get rid of it") or "create credit" which creates a credit on the customer's account that can be applied to future payments. This is not the same as a gateway credit.

Gateway credit - this means your merchant is depositing money into the cardholder's account. This is typically done as a credit by reference, which means that the credit is tied (referenced) to a prior payment. A credit is sometimes called a refund in the case of a credit by reference.

Where this can get confusing is that when you void a non-closed payment in netFORUM, it didn't used to void the associated transaction in the gateway; instead it would do a gateway credit by reference. And when you void a payment in netFORUM and choose to "create credit", it creates a credit in netFORUM, but not a credit in the gateway.

Under the new changes, when you attempt in netFORUM to void a full payment (all payment line items), then netFORUM will attempt to void the payment in the gateway, instead of attempting to create a credit by reference in the gateway.

The payment gateway will generally approve a void payment request from netFORUM as long as the payment hasn't been fully settled; settlement typically happens daily. So, if you void a same-day payment in netFORUM, then the the void in the gateway should succeed. If you attempt to void in netFORUM a week-old payment, then the gateway will decline the void.

If the gateway declines the void (most likely because the payment has already settled), then when netFORUM gets the decline response from the gateway, netFORUM will immediately respond by sending to the gateway a credit by reference request for the voided amount.

The benefit of this logic is that your merchant account and your consumers will see these voided payments drop off your statements and the cardholder's statement, instead of having a deposit followed by a refund for the same amount. This is cleaner for everyone.

in the earlier versions of netFORUM, when you void a same-day non-closed payment, your merchant account will wind up with an offsetting deposit and credit and therefore more reconciliation lines to look through. But when a non-settled payment is voided, by contrast, those transactions won't appear in a gateway settlement report because they essentially disappear. (They are still available in the gateway for viewing, however.)

The deposit + offsetting credit/refund is also not desirable for the consumer. Since same-day voids are typically caused by a mistake or a case of immediate buyer's remorse, the consumer would prefer to see the pending payment "disappear" from their account instead of seeing, for example, a $99 payment followed by a $99 credit (or refund) on the same day.

Note that all of these changes happen on the gateway side. A netFORUM user in iWeb won't know the difference when performing these transactions. In case you were curious, nothing will be change in how netFORUM accounting batches are handled -- before and after this change, a non-closed payment that is voided in netFORUM won't result in a ledger record, whether the related transaction in the gateway got voided or credited.

So although this internal change to the netFORUM void payment operation won't result in anything looking different in netFORUM, be aware that you'll start to see differences in your gateway transactions:

• Change: Most same-day void payments in netFORUM will result in voided captures/settlements in the gateway.
• Same: netFORUM non-closed payment voids will not generate ledger records when the batch is closed. The invoice will result in a debit to AR and a credit to revenue, but that's it.
• Same: netFORUM partial payment voids will result in a credit by reference in the gateway.
• Same: netFORUM payment voids of payments that have already settled in the gateway will result in a credit by reference in the gateway.
• Same: netFORUM payment void-with-adjustment of closed netFORUM payments will result in a credit by reference in the gateway; the netFORUM accounting batch will contain ledger records to credit cash and debit AR, in order to reverse the prior payment.

Keep in mind that in netFORUM, you can only void a payment if the payment's batch hasn't been closed yet. After the payment batch has been closed, then you can do a return or a void with adjustment. Either of these operations will result in netFORUM attempting a credit request to the gateway, not a void request. This logic has not changed.

If the original payment has multiple line items, and you want to void the payment for only some of them, or for only one, then netFORUM will send a credit by reference request to the gateway for the amount, instead of a void request. The reason for this is that electronic payment gateways do not support a partial void, only a full void. Since in this scenario you want to keep some of the payment, netFORUM instead sends to the gateway a credit-by-reference only for the amount of the payment lines being voided. As an aside, for a scenario such as this, you might want to perform a return in netFORUM instead of a payment void.

For example, if you sell an order with three items: A for $10, B for $20 and C for $40, for a total payment of $70. For whatever reason, you need to void the payment for item B for $20. In this case, netFORUM will do a credit by reference attempt for $20 (which is the same behavior as in earlier versions). In your deposit statement, ultimately you'll see a $70 settlement and a $20 refund/credit. The consumer will see the same on their credit card billing statement.

The same restriction occurs if you try to void any line items when you had already voided one of the other payment items earlier (which would have resulted in a credit by reference for the amount you are voiding). For example, using the scenario above with items A, B, and C. Suppose in netFORUM you void the payment item for A; this will result in a $10 credit by reference.  An hour later you attempt to void the payment details for the other two line items B and C. In this case, netFORUM will do a credit by reference for B and C.
 

Vantiv

Q. When attempting to make an electronic payment with an ACH payment method, using the Vantiv payment processors, I get an error "​merchant is not authorized for eCheck tokens". What do I need to do to fix this?

A. Contact your payment processor and ask them to configure your merchant account to accept electronic checks as a payment method.  For most processors, this is not a default configuration for a merchant account so you need to turn this on.

Q. is there a list of error codes and test credit card numbers for transactions processed by Vantiv?

A. Navigate to Vantiv's developer portal: ​TechTools API & Resource Index | Vantiv O.N.E.

Next, click the link for ​eCommerce XML Specification​, and download the PDF document. Section A has response and error codes and explanations and Section C has test card numbers that simulate various approvals and declines in the test environmewnt.

Sage

Q. When attempting to make an electronic payment with an ACH payment method, using the Sage payment processors, I get an error "SERVICE NOT ALLOWED ". What do I need to do to fix this?

A. Contact your payment processor and ask them to configure your merchant account to accept electronic checks as a payment method.  For most processors, this is not a default configuration for a merchant account so you need to turn this on.

Q. Is there a list of Sage error codes and explanations of the error codes?

A. Yes, see: Sage Knowledgebase - ​Error: Decline Codes for Virtual Terminal​.

Deactivating a Merchant Account

Q. I have frozen my merchant account, so users cannot create any new payments for that merchant account, but users are still able to create refunds for older payments on this merchant account if they return the payment and process an electronic refund. We don't want people to do that. We cannot deactivate the merchant account in the gateway itself because we still use that merchant account for other applications outside of netFORUM. [Note: this applies to netFORUM versions with new advanced payment processing features that were introduced along with the the "PaymentProcessingModel" system option; if your netFORUM instance does not have this system option, then this does not apply to you.]

A. As you noted, when you "freeze" a merchant account (or a gateway or payment method) then netFORUM freezes it only for new payments. Existing payments against that merchant account before your froze it are still "live" for capturing, voiding or refunds. If you truly want to deactivate the merchant account entirely in netFORUM, then we recommend that you update the "password" property in the merchant account setting to an invalid value. After you do this, if a user attempts to void or refund a payment, it will fail with an error message because netFORUM won't be able to connect to the payment gateway. We also recommend that you rename the merchant account and gateway to "Legacy Account - Deactivated - No longer Operational" or something similar so that users don't get confused or try to "fix" the problem.