Saturday, March 28, 2009

Nacha ACH Return Codes

If your company does any kind of eCheck ACH processing you'll want to get familiar with at least a couple of these return codes from NACHA.





























































































































































































Return Code
Description
R01Insufficient Funds
R02Account Closed
R03No Account/Unable to Locate Account
R04Invalid Account Number
R05Unauthorized Debit to Consumer Account
R06Returned per ODFIs Request
R07Authorization Revoked by Customer
R08Payment Stopped or Stop Payment on Item
R09Uncollected Funds
R10Customer Advises Not Authorized
R11Check Truncation Entry Return
R12Branch sold to another DFI
R13RDFI not qualified to participate
R14Representment payee deceased or unable to continuein that capacity
R15Beneficiary of account holder deceased
R16Account Frozen
R17File record edit criteria
R18Improper effective entry date
R19Amount field error
R20Non-Transaction Account
R21Invalid company identification
R22Invalid individual ID number
R23Credit entry refused by receiver
R24Duplicate entry
R25Addenda error
R26Mandatory field error
R27Trace number error
R28Routing number check digit error
R29Corporate customer advises not authorized
R30RDFI not participant in check truncation program
R31Permissible return entry
R32RDFI non-settlement
R33Return of XCK entry
R34Limited participation DFI
R35Return of improper debit entry
R36Return of improper credit entry
R38Stop Payment on Source Document
R40Return of ENR entry by Federal Government Agency (ENR Only)
R41Invalid transaction code (ENR Only)
R42Routing number/check digit error (ENR only)
R43Invalid DFI account number (ENR only)
R44Invalid individual ID number (ENR only)
R45Invalid individual name/company name (ENR only)
R46Invalid representative payee indicator (ENR only)
R47Duplicate enrollment
R50State Law Affecting RCK Acceptance
R51Item is Ineligible, Notice Not Provided, Signature not genuine
R52Stop Payment on Item
R61Misrouted return
R62Incorrect trace number
R63Incorrect dollar amount
R64Incorrect individual identification
R65Incorrect transaction code
R66Incorrect company identification
R67Duplicate return
R68Untimely Return
R69Multiple Errors
R70Permissible return entry not accepted
R71Misrouted dishonored return
R72Untimely dishonored return
R73Timely original return
R74Corrected return
R80Cross-Border Payment Coding Error
R81Non-Participant in Cross-Border Program
R82Invalid Foreign Receiving DFI Identification
R83Foreign Receiving DFI Unable to Settle
Change CodeDescription
C01Incorrect DFI Account Number
C02Incorrect Transit/Routing Number
C03Incorrect Transit/Routing Number and Incorrect DFI Account Number
C04Incorrect Individual Name
C05Incorrect Transaction Code
C06Incorrect DFI Account Number and Incorrect Transaction Code
C07Incorrect Transit/Routing Number, Incorrect DFI Account Number, and Incorrect Transaction Code
C08Reserved
C09Incorrect Individual Identification Number
C10Incorrect Company Name
C11Incorrect Company Identification
C12Incorrect Company Name and Company Identification
C13Addenda Format Error
C61Misrouted Notification of Change
C62Incorrect Trace Number
C63Incorrect Company Identification Number
C64Incorrect Individual Identification Number
C65Incorrectly Formatted Corrected Data
C66Incorrect Discretionary Data
C67Routing Number Not From Original Entry Detail Record
C68DFI Account Number Not From Original Entry Detail Record
C69Incorrect Transaction Code

Sunday, March 15, 2009

How to make your software application PCI compliant.

If your a developer who maintains a software application that accepts credit card payments you may be wondering how to make your program PCI compliant. Your not alone, every piece of software that accepts credit card payments or stores credit card numbers is now forced to become PCI complaint or be fined. PCI or the Payment Card Industry regulates the storing and transmission of credit card numbers.

Your options
There are two ways to become PCI compliant.
1. Subject your software application to a PCI audit. Representatives from the Payment Card Industry will review your application and make recommendations for the storage and transmission of credit card data. The audit will be intensive and costly and will need to be redone annually.
2. Rework your application to stop the storage and transmission of credit card numbers. At first this sounds foreign but read on.

Removing the storage and transmission of credit card numbers from your application.
Lets say for example you have a software application that accepts rent. Landlords use it on their desktop computers. They select a renter and charge their credit card.
We need to remove the portion that stores the credit card and replace it with a payment token. The token is generated when the landlord enters the credit card on a PCI certified site from your payment processor. Once you have the token you can store it in your application instead of the credit card number. When your ready to charge the renter you send the token along with the amount. Its that simple, your now PCI complaint.

PCI compliance in a few steps.
It doesn't have to cost a fortune to become PCI compliant just a small change your application can make all the difference. Often the change can be made in a way that your customers won't even notice.

The Benefits of Electronic Payments for B2B Transactions

In the digital age, businesses are increasingly moving away from traditional payment methods such as checks and cash, and adopting electroni...