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
R01	Insufficient Funds
R02	Account Closed
R03	No Account/Unable to Locate Account
R04	Invalid Account Number
R05	Unauthorized Debit to Consumer Account
R06	Returned per ODFIs Request
R07	Authorization Revoked by Customer
R08	Payment Stopped or Stop Payment on Item
R09	Uncollected Funds
R10	Customer Advises Not Authorized
R11	Check Truncation Entry Return
R12	Branch sold to another DFI
R13	RDFI not qualified to participate
R14	Representment payee deceased or unable to continuein that capacity
R15	Beneficiary of account holder deceased
R16	Account Frozen
R17	File record edit criteria
R18	Improper effective entry date
R19	Amount field error
R20	Non-Transaction Account
R21	Invalid company identification
R22	Invalid individual ID number
R23	Credit entry refused by receiver
R24	Duplicate entry
R25	Addenda error
R26	Mandatory field error
R27	Trace number error
R28	Routing number check digit error
R29	Corporate customer advises not authorized
R30	RDFI not participant in check truncation program
R31	Permissible return entry
R32	RDFI non-settlement
R33	Return of XCK entry
R34	Limited participation DFI
R35	Return of improper debit entry
R36	Return of improper credit entry
R38	Stop Payment on Source Document
R40	Return of ENR entry by Federal Government Agency (ENR Only)
R41	Invalid transaction code (ENR Only)
R42	Routing number/check digit error (ENR only)
R43	Invalid DFI account number (ENR only)
R44	Invalid individual ID number (ENR only)
R45	Invalid individual name/company name (ENR only)
R46	Invalid representative payee indicator (ENR only)
R47	Duplicate enrollment
R50	State Law Affecting RCK Acceptance
R51	Item is Ineligible, Notice Not Provided, Signature not genuine
R52	Stop Payment on Item
R61	Misrouted return
R62	Incorrect trace number
R63	Incorrect dollar amount
R64	Incorrect individual identification
R65	Incorrect transaction code
R66	Incorrect company identification
R67	Duplicate return
R68	Untimely Return
R69	Multiple Errors
R70	Permissible return entry not accepted
R71	Misrouted dishonored return
R72	Untimely dishonored return
R73	Timely original return
R74	Corrected return
R80	Cross-Border Payment Coding Error
R81	Non-Participant in Cross-Border Program
R82	Invalid Foreign Receiving DFI Identification
R83	Foreign Receiving DFI Unable to Settle
Change Code	Description
C01	Incorrect DFI Account Number
C02	Incorrect Transit/Routing Number
C03	Incorrect Transit/Routing Number and Incorrect DFI Account Number
C04	Incorrect Individual Name
C05	Incorrect Transaction Code
C06	Incorrect DFI Account Number and Incorrect Transaction Code
C07	Incorrect Transit/Routing Number, Incorrect DFI Account Number, and Incorrect Transaction Code
C08	Reserved
C09	Incorrect Individual Identification Number
C10	Incorrect Company Name
C11	Incorrect Company Identification
C12	Incorrect Company Name and Company Identification
C13	Addenda Format Error
C61	Misrouted Notification of Change
C62	Incorrect Trace Number
C63	Incorrect Company Identification Number
C64	Incorrect Individual Identification Number
C65	Incorrectly Formatted Corrected Data
C66	Incorrect Discretionary Data
C67	Routing Number Not From Original Entry Detail Record
C68	DFI Account Number Not From Original Entry Detail Record
C69	Incorrect Transaction Code

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.