Credit Card Payment Method

Overview:

The credit card payment method allows customers to checkout using their credit card.

There are two (2)  general methods for accepting credit cards:

1. Real Time Transactions: This is where the customer's credit card is charged in real-time by the shopping cart during checkout. The customer and store get an immediate accept/decline from the Payment Gateway that you are using. The Payment Gateway then clears the funds to your checking account using the banking system (that part is outside our control).

2. Manual (Offline Processing): This is where you just want to accept orders, with credit card #'s, and use some "outside" (of the store site) method to process them. To do this, you must set AppConfig:StoreCCInDB=true. Also, the CCV code CANNOT be stored for later entry due to Visa/MasterCard/Amex regulations. So if you are processing orders "offline" somehow, you CANNOT save and store the CCV code.

To enable credit card payments:

        Set AppConfig:PaymentMethods=CREDIT CARD

NOTE: MULTIPLE payment methods CAN be set.

Security Concerns:

By default, we ship AspDotNetStorefront with AppConfig:StoreCCInDB=false! So by default, NO credit cards information are stored anywhere in the database. This is the safest method, and highly recommended if possible. However, if you have to store credit cards (you have recurring products, manual transactions, etc), then the credit card information in the database fields will be encrypted (only IF customers "save credit card info" flag is set to allow it), and only visible to the store admin users and of course the payment gateways where the transactions are sent to. We recommend that you do not store credit cards unless you have to. It's just an increased liability for your business. Also, if you ARE storing credit cards in your database, even if they are encrypted, we recommend that you follow the recommended monthly maintenance procedures to wipe them out of old orders, old address records, etc. There simply is no need to continue to store a credit card on an order that is over 45/60 days old (unless it's a recurring billing item). Following this recommendation can greatly decrease the risk to your business should the server be compromised for any reason.

It is YOUR responsibility to ensure your database, website is located in a secure facility, with proper access controls to the data in your database. If you do not want to invest the time and effort into ensuring security, we recommend you disable storing all credit card information in the database. See Security Best Practices.

Recurring Orders

If your store has recurring orders, then you will need to store credit card numbers. Again, you have to set AppConfig:StoreCCInDB=True. For recurring orders, credit card numbers will be saved even if the customer does NOT want it saved.

Credit Card Verification (CCV) Codes

The CCV Code (3 or 4 digit code on the back of cards) is NOT stored in our systems to comply with visa / master card requirements. If you require this information to process your orders outside AspDotNetStorefront, then consider that before choosing gateways or determining how you plan to process credit card orders. You can specify whether the CCV code is optional, or required (recommended) when customers place orders by specifying the AppConfig:CardExtraCodeIsOptional=true/false AppConfig.

 

Real Time Transactions

To use Real Time transactions, you must obtain an Internet Merchant Account. They will also provided you with a Payment Gateway (which must be one we support). You will then follow the manual instructions to configure & enable this gateway. Generally, the gateway's also do all Address Verification System (AVS) declines, we do NOT ever decline based on AVS code/status. The gateways all let you define what AVS conditions should fail a transaction, so there's no point in us replicating all that in the store site. We do store the AVS status code with each order, which you can view in the admin site.

The original transaction mode of AspDotNetStorefront can be set to AUTH (only) or AUTH-CAPTURE. AppConfig:TransactionMode specifies this setting.

An AUTH just authorizes the charge, but does NOT capture or transfer funds. You have to manually "capture" the transaction later in the admin site by clicking the CAPTURE button.

AUTH-CAPTURE authorizes and captures the transaction all at once. Funds are not "yours" until they are captured. Most gateways (but not all) support both modes. Generally, if you are shipping same-day products, or services, or downloads, you would be using AUTH-CAPTURE. If it takes you some time (days, weeks) to process and actually ship an order, you should AUTH it only, and then CAPTURE when shipped.

Transactions can be in several states:

• AUTHORIZED

• CAPTURED

• REFUNDED

• VOIDED

See more in Capture, Voids, Refunds.

The admin site lets you perform these actions on orders (where allowed). VOID is usually only valid on the same day a transaction is received. After that, you must use REFUND.

NOT ALL GATEWAYS SUPPORT ALL ACTIONS! Consult the gateway manual to see what they support. Also, at times, you MAY HAVE to use the actual payment gateway "web site interface" to perform certain actions. Not all information from all transactions are available to the storefront. It's rare to need to use the actual payment gateway website, but do know it is there, and will be needed at times! Gateways do NOT report all information back to us in the storefront, so we're sometimes limited by what information they send back!

Manual Transactions

If you are processing the credit cards through some other system, you can set the AppConfig:PaymentGateway=MANUAL. You must also set AppConfig:StoreCCInDB=true, so the storefront stores the credit cards (encrypted) in the db with the order. The CCV code is NEVER stored, and not available in this mode. After you process the order, you must manually go to the admin site and click the "Mark Payment Cleared" button on the order, so the storefront knows that you have processed the card.

 

Credit Card Types

You can control which credit card types are allowed (which may be specific to your merchant account, and internet payment gateway). You can edit these in the admin site under Misc -> More -> Credit Card Types menu. You also then have to edit the graphic that the store shows on the payment collection page to match the credit cards that you are allowing. We don't update that graphic automatically. See also Credit Card Types Menu.

Voiding Orders

To void an order (undo it), generally valid only on the same day it was received, before the transaction batch for the day "settles", click the "void" button on the order. Then delete the order, as it is not needed.

See more in Capture, Voids, Refunds.

Capturing Orders

IF you are using AUTH (only) mode, and then want to CAPTURE the order, click the CAPTURE button. The transaction state will then move to "CAPTURED" and the next batch settlement will capture those funds to your account. CAPTURE button only appears if the Transaction State is "AUTHORIZED".

See more in Capture, Voids, Refunds.

Refunding Orders

To fully refund an order, click the "REFUND" button. You can then delete the order, or leave it there, with it's TransactionState marked as "REFUNDED". You will be prompted to enter a reason for the refund, which is stored with the order, just for later records.

See more in Capture, Voids, Refunds.

Ad-Hoc Refunding Orders

If you need to do a partial refund (e.g. refund $10 for extra shipping) or partial "added charge" (e.g. add $7 for extra shipping), that is what the AdHoc order does. It creates a child order of this order with either a charge transaction or a credit transaction.

Mark As Fraud

If an order results in a fraudulent transaction and you get a later chargeback from the bank, click the "Mark As Fraud" button on the order. This moves the order records OUT of the live order tables into the quarantine "FraudOrders_XXX" tables for later forensics if needed. You can also just DELETE the order if you want (we recommend moving it to fraud in case the FBI needs that information later).