The
organization must have a valid token for a credit card in order to process
credit card refunds.
Within this section, you’ll find definitions of common terms used in the Personify Credit Card Processing Subsystem, as well as the Personify Accounting Subsystem.
Merchant's bank that accepts credit card payments on behalf of the merchant (i.e., Visa or Mastercard). The acquiring bank creates a contract (known as the merchant account) with the merchant. This contract ensures the acquiring bank exchanges funds with the issuing bank on behalf of the merchant.
Referred to in Personify, simply as “processor.” Acquiring processors provide credit card authorization, settlement and services to acquiring banks through payment handlers.
In Personify, also referred to as a "Pre-Authorization".
The process of verifying a customer's credit card and verifying that the cardholder has the funds available against their line of credit.
Note, the authorization doesn't actually charge the card. A positive authorization results in an authorization code generatation and the cardholder's available credit limit or "amount open to buy" reduced by the authorized amount. The hold on the cardholder's available credit limit lasts for the amount of time specified by the cardholder's issuing bank (typically a week, but the number of days depends on the bank).
The merchant receives their funds when the credit card is settled after the organization runs the CCP610 batch process. When credit cards are settled, the authorization number passes to the payment handler.
In Personify, if an organization wants to allow a customer to make payments according to a payment schedule, an Auto-Pay Method is entered on the order line via the Payment Schedule Parameters (ORD001_PaymentScheduleParameters) screen. You can access this screen from the “Work with Payment Schedule” task under the “Work with Line Items” task category of the Order Entry screen.
For credit card payments, the Auto-Pay Method is set to "CC" for Credit Card. Scheduled credit card payments are processed by the FAR680 batch process.
For Electronic Funds Transfer (EFT) payments, the Auto-Pay Method is set to “DD” for Direct Debit. Scheduled EFT payments are processed by the EFT680 batch process.
AVS is a service used on all credit card transactions that occur when the actual card is not present and the user types in the card information, such as for an online purchase. AVS works by the merchant entering the street address and zip code at the time of transaction, along with the card number, expiration date, and amount. When a transaction is submitted for authorization, the address and zip code entered are checked against the actual billing address and zip code for the card holder. The AVS response is actually provided by the issuing bank.
PayPal can be defined to ignore AVS. If there are AVS code responses that should be rejected, those are defined in application interface parameters.
If a customer puts a limitation on his/her credit card (e.g., don't approve a transaction totaling more than $500), the credit card company won't approve the transaction but instead presents a message in the back-office asking the end user to call the credit card company for a manual authorization. On the payment entry screen, after the user obtains the manual authorization number, the user clicks the "manual authorization" checkbox and enters the manual authorization number.
To convert the authorization amount into a billable transaction record within a batch.
Transactions cannot be captured unless previously authorized and the goods or services have been shipped or transmitted to the consumer.
The company that brands the credit/debit card (Visa, MasterCard, etc.) and allows the banks to issue them.
See "CVV" below.
CCP is a subsystem in Personify. By using this subsystem in conjunction with other subsystems, such as the Order Entry subsystem, you can process credit card receipts for non-inventoried and inventoried products, schedule a credit card payment, process receipt reversals, process receipt refunds, and process a credit card via the Web.
CCP is also the naming convention for the first three letters in the batch process name for credit card processing batch processes.
The following is a lit of credit card processing reports available in Personify.
Credit Card Transaction Analysis Batch Process - This batch process retrieves any credit card transactions created between a user-defined period of time and lists them in a report.
The user has the option of grouping different transactions together to facilitate daily/monthly reconciliation.
Credit Card Settlement Batch Process - This batch process facilitates credit card reconciliation by issuing post-authorizations for pre-sale transactions, issuing post-credits for pre-credit transactions, and creating an exception report of pre-sales with invalid receipts or vouchers and a listing of all transactions for the day.
Errors that occured during a CCP610 batch job and are listed in the exception report.
Critical errors are listed in red and are issues that prevent the credit card from being settled; the issues are either with the credit card or relate to rules defined by the payment gateway that are being violated.
Warning errors occur when there is an authorization but the receipt doesn't exist in Personify, caused by a receipt reversal to void the charge.
Credit Card Retokenization - This batch process is for organizations using PayPal as their payment handler. CCP650 generates reference transactions to obtain new tokens for credit cards being used for automatic renewal of memberships or subscriptions, recurring gift payments or for other scheduled payments where the current token will expire before the credit card is scheduled to be used to pay the renewal, recurring gift or scheduled payment.
Credit Card Analysis - This batch process is used to reconcile credit card batches. CCP1401 is the same as CCP504, except it is an online report rather than a batch report. Please refer to CCP504 for more information.
Scheduled Deferred Receipt Processing. This batch process creates deferred receipts to allow for installment payments for order lines (such as memberships, subscriptions, exhibitions and fundraising pledges), either automatically through credit cards or direct debit or through paper invoices or pledge reminders.
Recurring Fundraising Gifts Processing. When donors make recurring gifts, this batch process processes the next gift on or after the "Next Gift Due" date as defined on the recurring gift order line. For recurring gifts being paid by credit card, FND680 gets the credit card authorization as with any credit card order line, and CCP610 then processes the credit card payment for settlement.
Renewal Processing. If a membership order is set with an auto payment method of credit card, when the membership is renewed, the ORD650 renewal batch process will bring this payment method forward to the renewed order along with the credit card data. If the credit card data is not on the original order, the credit card of record will be obtained from the customer record by the renewal batch process.
A charge back results after a credit card payment has been processed by a merchant (i.e., an organization) and a customer disputes the charge, the credit card company then credits the money back to the customer and the bank removes the money from the organization's account.
When a customer initiates a charge-back, the bank sends the organization a charge-back notice, informing the organization that the bank has removed money from the organization's account. In Personify, a receipt reversal is done to reverse the payment, so that the credit to the customer's credit card is not processed again.
Used by receipt screens and by web users who may want to save and use the same credit card for future payments. When a credit card of record is entered, Personify obtains a credit card token which is saved in the Cus_Credit_Card_Profile table.
The number on a cardholder's credit card. In Personify, only the first 7 and last 4 digits of a cardholder's credit card number is stored. On reports and screens, only the cardholder's last 4 digits of the credit card number are displayed.
Credit card payments can be refunded either by credit card or by check. If the credit card has expired since the payment was entered, the new expiration date can be entered on the refund screen, but a refund can also be processed to an expired credit card. See also "Presettled Credit Card Refund".
The
organization must have a valid token for a credit card in order to process
credit card refunds.
As of 7.2.2, credit card payments processed through a lockbox can be refunded through Personify, if the organization uses the same merchant as the bank that processed the lockbox payments and if the lockbox bank returns the credit card token.
For organizations refunding payments through CyberSource, credit cards refunds can be made:
· Up to 60 days after the credit card payment, or
· There is a token on the customer profile obtained in one of the scenarios in the Token assignment for CyberSource section and the "Force Refund" flag is set to Y.
· If the organization can enter the full credit card number for processing the refund.
Otherwise, the refund to the customer will need to be made by check.
For organizations refunding payments through PayPal, credit card refunds can be made:
· Up to a year after the payment or up to a year after the latest settled token (obtained from CCP610) for the credit card used to be refunded, or
· If the organization can enter the full credit card number for processing the refund.
Otherwise, the refund to the customer will need to be made by check.
A credit card reversal voids the credit card payment entered in the system. Reversals can only be done on the same day as the credit card payment. A credit card reversal prevents the processing of the receipt. However, this does not release the hold put on the funds by the pre-authorization. The workaround is to issue a refund, rather than doing a reversal, so that the payment and the refund are processed at the same time. Both the payment and the refund appear on the customer's credit card statement.
For the purposes of testing, there are certain credit card numbers you can enter in the system in order to achieve an “Approved” or “Declined” status.
Credit Card |
Number |
|---|---|
American Express |
n/a |
Discover |
n/a |
MasterCard |
5111111111111111 |
VISA |
4111111111111111 |
Credit Card |
Number |
|---|---|
American Express |
340682458348749 |
Discover |
6011191466819647 |
MasterCard |
5116381817387388 |
VISA |
4116196783374209 |
A table in Personify that stores secured customer credit card information, including credit card tokens and the date of each credit card token.
Card Verification Value code. The three digit code printed on the back of Visa, Mastercard and Discover credit cards. American Express uses a four-digit code. The code is used primarily to validate transactions paid with a credit card in online transactions, where the card holder is not present for validation, such as online purchasing. The CVV code is sometimes also referred to as "Card Security Code".
PayPal can be defined to ignore CVV codes. If there are CVV codes that should be rejected, those are defined in application interface parameters.
A payment handler supported in Personify.
In Personify, CyberSource is selected as the organization's payment handler by activating the "CYBERSOURCE" payment handler code in system types where Subsystem = 'CCP' and Type = 'PAYMENT_HANDLER'. Parameter values needed for processing credit card payments through CyberSource are then defined in the Application Interface subsystem under the interface name "CYBERSOURCE".
The URL for CyberSource's test server is: https://ics2ws.ic3.com/commerce/1.x/transactionProcessor. The URL for CyberSource's transaction website is: https://ebc.cybersource.com.
The date in which a pre-authorization is no longer valid for a deferred credit card payment authorization. The credit card payment needs re-authorization to create a new Pre-Auth record.
This refers to backordered inventoried products only (not to be confused with deferred batches or deferred receipts). When "Deferred Credit Card Processing" for inventoried product sales is set to 'Y', credit cards are not processed for payment until the inventoried product is shipped to the customer.
Each association can decide whether they want to use the deferred credit card processing feature by setting the system parameter. The system parameter is found in the TimssInterfaceServer file. To use the feature, a "Y" should be updated as shown highlighted and in red below to the <CCP_DEFERRED_SUPPORT> line in the TimssInterfaceServer file:
<CCP_DEFERRED_SUPPORT>Y</CCP_DEFERRED_SUPPORT>
A best practice recommendation for backordered inventoried products is to notify the customer when the order is placed that the product is not available for immediate shipping, but will be shipped within 30 days, and that the customer's credit card will not be charged until the item is shipped. The customer should be given the option to cancel their order during that time.
If the product is not available after 30 days, a second communication should be sent to the customer informing them that the item is not yet available, and that the customer should contact the organization if they would like their order cancelled; otherwise, the product will be shipped within 30 days.
If the product is still not available after 60 days, the best practice recommendation is that the order should be cancelled.
The
Credit Card Retokenization batch process will not attempt to re-tokenize
a credit card for a back-ordered inventoried product even if the order
is almost a year old, because it is considered bad practice to maintain
a backorder for that long.
For scheduled payments due in the future, a deferred payment transaction is created for the sum or all scheduled payment amounts with a due date in the future that have a payment status of "PENDING". Deferred payment transactions (also referred to as "Scheduled Amounts") have a Type 9 transaction type.
When FAR680 is run and scheduled payments are processed, scheduled payments with a due date on or before the due date being processed for FAR680 are selected for payment processing, and the deferred payment amounts are reduced by the amount paid or increased by the amount due if payment was not successfully processed.
Electronic funds transfer or EFT is the electronic exchange or transfer of money from one account to another, either within a single financial institution or across multiple institutions, through computer-based systems.
EFT is one type of auto-payment that Personify supports. It uses a standard Automated Clearing House (ACH) file. Transactions received by the financial institution during the day are stored and processed later in batch mode. Rather than sending each payment separately, ACH transactions are accumulated and sorted by destination for transmission during a predetermined time period.
Parameter defined for each payment handler in the Application Interface configuration, and identifies the period of time in days that the payment handler stores the original sale information.
Refunds to a credit card can only be done for as long as the payment handler maintains the original sale information.
For PayPal, the value is set to 355, meaning that a refund can be made to a customer's credit card for a year and a couple of days after the original sale.
For Cybersource, the value is set to 59, which means that a refund can be made to a customer's credit card if made within 2 months of the sale.
A forced refund is a refund that the payment handler will process even though it is not against a sale that the payment handler has a record of. Whether to allow a forced refund is a parameter value that is defined as a subcode in system types and codes for payment handlers.
The bank that issued the credit card to the purchasing customer. When a credit card is used to make a payment, it is the issuing bank that provides the authorization or decline and collects the money form them for the purchase.
Lockbox processing refers to payments received via an electronic lockbox file. Typically, you will work with the bank to build a file appropriate for Personify. Any other method, such as payments directed to a PO box or picked up by a bank, is not considered lockbox processing.
In general, a lockbox is a Post office box (PO box) that is accessible by the bank. A company may set up a lock box service with their bank for receiving customers payments. The company's customers send their payments to the PO box. Then the bank collects and processes these payments directly depositing them to the company's account. Typical costs are around $100 per month with per-item fees for basic service, and upwards of $500 for businesses with high check volume.
The entity selling the product or service being purchased by a customer. In Personify, the merchant is the TMA customer organization.
The merchant (i.e., TMA customer organization) gets a merchant account from their bank. The organization's merchant account information is defined at the organization unit level in Interface Configuration.
Before a merchant account can be defined in Personify, the payment handler must be selected. In Personify, a currency is associated with a merchant account; a merchant account can only have one currency. Once the merchant account has been configured in Personify, the merchant can be associated with one or more receipt types.
It is common for organizations to have a different merchant account for their web sales from the merchant account for their back-office sales.
The bank that enables merchants to accept credit cards. It is from the merchant's "acquiring" bank that the merchant receives a merchant account.
A merchant has a merchant account with their merchant bank, and each day the merchant deposits the value of the day's credit card sales with their merchant bank.
The vendor name used for logging on to the PayPal Manager website – only used with PayPal. This is required to process transactions.
As defined by Payment Card Industry (PCI), a payment application is any software that accepts credit cards as payment. Personify is a payment application, and as of version 7.1.1 is PA-DSS certified. For an organization to be able to accept credit cards, the organization must be in compliance with PCI-DSS, which requires that all payment applications used by the organization be PA-DSS certified.
Payment Application Data Security Standard - PA-DSS requirements are defined by PCI, the Payment Card Industry, and define security requirements and practices designed to prevent credit card theft and fraud.
The requirements for PA-DSS are derived from the Payment Card Industry Data Security Standard (PCI DSS) Requirements and Security Assessment Procedures. Documents can be found at www.pcisecuritystandards.org.
Since Personify is a payment application, Personify must be PA-DSS certified in order for an organization using Personify to be in compliance with PCI-DSS.
The secure pipe between the banks and the processor. The payment gateway is provided by the Payment Handler.
The vendor offering payment processing services and payment gateway services.
The term "Payment Handler" is sometimes used interchangeably with "Payment Network", but in Personify, "Payment Handler" is the term that is used.
Personify currently supports PayPal (formerly Verisign) and Cybersource as payment handlers. An organization can only have one payment handler.
The first step in defining the organization's payment handler is to activate the organization's selected payment handler in system types and codes where the subsystem = 'CCP' and the Type = 'PAYMENT_HANDLER' by setting the Active flag to 'Y' for the selected payment handler and setting the Active flag to 'N' for the other payment handlers. The payment handler codes are 'CYBERSOURCE' for Cybersource and 'VERISIGN' for PayPal. By default, Personify is delivered with 'VERISIGN' defined as the active payment handler.
Once the organization's payment handler is defined in system types and codes, application parameter values are defined in Interface Configuration for the selected payment handler (again, VERISIGN is the code used for PayPal).
After the organization's payment handler is defined, at least one merchant account must be defined.
In Personify, a payment handler can be associated with a receipt type record.
In Personify, payment handler parameters are defined in the Application Interface subsystem. The Interface name for PayPal is "Verisign", and the interface name for Cybersource is "Cybersource".
Another term used for Payment Handler.
The Payment Handler provides a payment processing service that connects merchants, customers, and banks through secure online transactions.
In Personify, if an organization wants to allow a customer to make payments according to a payment schedule, an auto-pay method is entered on the order line, and the payment schedule is then defined. Typically this is used for fundraising pledge payments, exhibition orders and sometimes for membership or subscription payments.
For credit card payments, the auto-pay method is set to "CC". Scheduled credit card payments are processed by the FAR680 batch process. All scheduled payments with a due date on or before the FAR680 run date and a payment status of "PENDING" will be picked up by the FAR680 batch process and authorized.
The payment gateway used by Personify when the organization configures Personify to use PayPal as the processor.
A payment handler supported in Personify.
In Personify, PayPal is selected as the organization's payment handler by activating the "VERISIGN" payment handler code in system types where Subsystem = 'CCP' and Type = 'PAYMENT_HANDLER'. Parameter values needed for processing credit card payments through PayPal are then defined in the Application Interface subsystem under the interface name "VERISIGN".
PayFlowPro is the payment gateway used by PayPal.
The URL for PayPal's test server is: https://pilot-payflowpro.paypal.com. The URL for PayPal's production server is: https://payflowpro.paypal.com. The URL for PayPal's setup and transaction-management website is: https://manager.paypal.com.
Payment Card Industry. PCI defines PCI-DSS and PA-DSS data security standards for using credit cards.
The payment card industry (PCI) denotes the debit, credit, prepaid, e-purse, ATM, and POS cards and associated businesses.
The term is sometimes more specifically used to refer to the Payment Card Industry Security Standards Council, an independent council originally formed by American Express, Discover Financial Services, JCB, MasterCard Worldwide and Visa International on Sept. 7, 2006, with the goal of managing the ongoing evolution of the Payment Card Industry Data Security Standard.
Payment Card Industry Data Security Standard - In order to accept credit cards for payment, an organization must be in compliance with PCI-DSS data security standards, sometimes also referred to as being PCI-compliant. One of the security standards that must be met is that all payment application software, such as Personify, used by the organization must be PA-DSS certified. Requirements for PCI-DSS can be found at www.pcisecuritystandards.org.
Another term for settlement. See Settlement Processing.
"Authorization" and "pre-authorization" are the same thing. This pre-authorization puts a hold of the relevant amount on the credit card for a specified number of days (typically a week, but the number of days depends on the bank).
A presettled credit card payment is a payment that has been processed for payment outside of Personify; credit card payments processed through a lockbox are presettled.
Presettled credit card payments are entered into Personify using a batch identified as containing presettled credit cards. Presettled credit card payments are not selected for settlement by the CCP610 batch process.
As
of 7.4.0SP1, the system will follow specific rules to validate credit
cards using a pre-settled batch. If user enters full numbers (all numerals
and length equal to length of the credit card from receipt type definition
(like 4111111111111111), the system will validate the credit card. If
the user enters non numeric data (like 4111*1111, then the system will
insert more asterisks to make it full length (like 4111********1111) and
will not validate the credit card. If the user enters numeric data less
than the required length (like 1111), then the system will prefix asterisks
to make it full length (like ************1111) and will not validate the
credit card. If the user enters less than 4 numeric digits or a length
that is more than what is defined in APP003, then the system will display
a validation message. The system will accept alphanumeric characters.
A credit card refund that has been processed outside of Personify. To record a presettled refund in Personify, a Receipt Reversal is done, and the system will handle the presettled refund as a charge back.
Also referred to as Acquirer or Acquiring Processor. The processor provides credit card authorization, settlement and services to acquiring banks through payment handlers. [Explain how the processor is obtained; is the relationship between the organization's bank and the processor, or does the organization contract with the processor? What does it mean when PayPal says that PayFlowPro is a processor?]
For authorizations, the processor sends authorization requests from payment handlers to issuing banks, and returns authorizations or declines from issuing banks to payment handlers, which are then sent to the merchant. For settlements, the processor sends settlement information from payment handlers to issuing banks and then sends settled transaction information from issuing banks to the merchant's acquiring bank. from merchants to and from issuing banks and acquiring banks that results in authorizing credit cards and settling funds for merchants. Many financial institutions don't do their own bankcard processing because it's more cost-effective to let a third-party vendor do it for them.
Processors that CyberSource and PayPal support include Vital, FDMS Nashville, Paymentech, NOVA, and First Data.
Processors supported by PayPal can be found at: https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/howto_gateway_payflow_processor.
Processors supported by Cybersource can be found in technical overview documents at www.cybersource.com.
When a credit card void or a charge-back is done by a customer, a receipt reversal is done in Personify to reverse the payment.
It is recommended that receipt reversals for charge backs be done with an adjustment batch set to the date of the charge back, which will help with reconciliation.
If the receipt reversal is done before the credit card has been settled, the "Charge Back" flag is not checked by the system, and the credit card payment is voided.
If the receipt reversal is done after settlement, the "Charge Back" flag is checked by the system. A receipt reversal for a charge back is not processed through the Payment Gateway, because the bank has already removed the money from the organization's account.
Each credit card receipt type is associated with a payment handler. Therefore, each receipt can have a unique merchant, or the merchant can be the same for all receipt types. Receipt Types are defined in Personify at the organization level through Organizational Unit Maintenance.
Cybersource refers to tokens as reference numbers. Please refer to “Token” for more information.
A term used by PayPal; refers to a transaction that is not a sales transaction but rather is a transaction done for the purpose of verifying the credit card and generating a token for the credit card.
Used in the CCP_Req_Ans table, the request type identifies the type of request made for a specific receipt on a credit card record. Request Types include Pre-Sale, Pre-Auth, Sale, and Credit. Information pretaining to credit card requests is found on the Credit Card Request Review (FAR015_Credit_Card_Request_Review) screen.
This is the process of creating reference transactions to generate new tokens for customers whose pre-authorization has expired.
The new token reference number and the date CCP650 was run will be updated to the Cus_Credit_Card_Profile table for each customer credit card processed successfully, and the Profile Reference Type Code will be set to "UPDATE-CUSTOMER-PROFILE." Credit cards that could not be retokenized will be listed on the CCP650 error report.
When CCP610 is run and credit card transactions are processed, CCP610 assigns a settlement number to each receipt. The settlement number format is month, day, year.
If the process is run more than once a day, the same settlement number is assigned. Pre-settled transactions will have -1 as the settlement number.
If a transaction has a blank settlement number, it means it has not yet been settled; when these show up on a credit card analysis report, these are typically web transactions authorized between the run of CCP610 and midnight.
The settlement number is stored in the following tables: CCP610_Req_Ans, CCP_Req_Ans, FAR_Receipt and FAR_Voucher.
The process by which credit card transactions are sent through the organization's payment gateway via the processor to the acquiring bank to the issuer so that monies due for credit card payments are taken from customers' credit card accounts and put into the merchant's (i.e., the organization's) account, and monies owed for credit card refunds are added to customers' credit card accounts from the merchant's account. Settlement is what occurs when the acquiring bank and the issuer exchange data or funds during that function.
In Personify, credit card settlement is done by running the CCP610 batch process. When the settlement process is run, a settlement number is assigned to each credit card receipt.
· Personify sends settlement request to CyberSource/PayPal (CCP610).
· CyberSource/PayPal sends a settlement request to the acquirer, who then routes it to Visa or MasterCard who routes it to the issuing bank or directly onto American Express or Discover.
· The issuing bank approves transfer of money to the acquiring bank (merchant bank).
Discover
and American Express act as their own issuers and acquiring banks.
The credit card token (Paypal) or reference number (Cybersource) replaces a credit card number in an electronic transaction. The token is a reference to the credit card, not to a transaction.
Tokens or reference numbers are meant to prevent the theft of credit card numbers during electronic transmission and storage of transactions. Since a token or reference number can't be used for transactions or fraudulent charges because it cannot be used without the credentials of both the payment handler and the merchant, there is little harm done if it's stolen (in fact, the token or reference number does not need to be encrypted).
The token is stored in the PROFILE_REFERENCE field in the Cus_Credit_Card_Profile table.
CyberSource assigns tokens that are good for as long as the customer credit card is good. Personify obtains a token in one of 3 scenarios for CyberSource:
· A credit card of record is entered.
· Credit card information is entered on an order line for scheduled payments.
· A credit card payment is entered for an inventoried product.
Personify does not need to obtain a CyberSource token for a non-inventoried product credit card payment because it is assumed that settlement (CCP610) will run within the authorization hold period and the authorization number will be passed to the payment handler for settlement.
PayPal assigns tokens that are good for one year. Personify obtains a token in one of the following scenarios for PayPal:
· A credit card of record is entered.
· Credit card information is entered on an order line for scheduled payments.
· A credit card is authorized for payment.
· A credit card goes through the payment settlement process.
A former payment handler that was acquired by PayPal.