Billing Zip Code vs Complete Billing Address

[twoods]

We are in the "live testing" phase of the PaaS API with a real customer. So far everything is working mostly smoothly. We recently encountered a decline situation with a debit card for which support helped determine that we really should always pass cards' billing zip code. For simplicity I haven't been requiring it. Here is C&P support's insight:

"If you do not pass the Zipcode to the API then we use the organization Zipcode – the zip code is required to run the transaction. While most transactionswill still get approved, any card-provider that checks the zip code will rejectthe transaction. ... Also, please note that if you do not pass the zip code of the donor/purchaserthe transaction is considered a “non-qualified” transaction. That adds a 1.5%surcharge. Please adjust your API calls to include the zip code of the donor/purchaser."

Please confirm that we are talking about the BillingPoastalCode in the BillingAddress (below)? Also, since everything is minOccurs="0", can we pass only the BillingPostalCode to get approval and avoid non-qualified fees? Or is there good reason to pass a complete billing address?

<xsd:element name="BillingAddress">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="BillingAddress1" minOccurs="0"/>
<xsd:element ref="BillingAddress2" minOccurs="0"/>
<xsd:element ref="BillingAddress3" minOccurs="0"/>
<xsd:element ref="BillingCity" minOccurs="0"/>
<xsd:element ref="BillingStateProvince" minOccurs="0"/>
<xsd:element ref="BillingPostalCode" minOccurs="0"/>
<xsd:element ref="BillingCountryCode" minOccurs="0"/>
</xsd:sequence>
</xsd:complexType>


-Tad

[CnP.Support]

Good day Tad,

Yes- the billing zip code is best to be sent.

In the absence of Zip Code most cards will be "downgraded", meaning they will be charged as a non-qualified card. If the information is missing we will pass the organization's zip code by default.

We actually expect the entire billing address to be sent as it is used by our fraud detection system. We highly recommend that you pass billing address & the phone number. All these parameters are used in monitoring for fraud. Making it easy for your donors will also make it easy for fraudsters to use your site.

I hope that answers your question.

Please let us know if we can be of any further assistance.

[twoods]

Ok, thank you for the fast reply. We will update to pass a full billing address.

-Tad

[twoods]

We are in the process of adding the customer's billing information, and I absolutely agree that it should be provided to further prevent fraud. As you say, "making it easy for your donors will also make it easy for fraudsters to use your site." However, for the record however and so not to appear naïve, let me explain what I mean by "making it easy" a little further....

With other payment gateways we occasionally have to explain to customers why a transaction was declined by us, but when they look at their card's account it shows that we billed it multiple times (once for every time they tried it again with a different address). This happens because, from our experience with other gateways in this situation, the card is actually approved by the bank but "declined" by the merchant gateway's strict configuration of the address validation. Of course the multiple charges are never reconciled and they "fall off" in 24 to 48 hours. Also in almost all of these cases the customer insists they have the right address. So (unfortunately?) it creates fewer customer "heart attacks" by disabling this address verification. I realized that some vendors and some industries simply must have the address verification on. We still collect and validate the address, we just don't configure the gateway to auto-decline in that situation. I assume something similar is happening with C&P; I am not aware that we have experienced that scenario with C&P.

[CnP.Support]

Good day!

We don't do AVS at first since it is costly. Each AVS request simply results in an authorization fee. Imagine if an organization is under attack by hackers as they attempt to authorize credit cards using various scripts - if we were to do checking for each card the organization will end up paying a lot of money for each authorization.

The experience you are sharing is because the way most companies work - we don't work that way. Here is what people do:

1. Post to gateway
2. Gateway responds authorization or decline. If the transaction authorizes the AVS code will be included in the response.
3. The application provider decides if they wish to report this as authorized or decline based on AVS
4. If AVS decision is to decline the application provider will post a reversal to the gateway to void the transaction

as you see the void is after the authorization. Once an authorization occurs the amount of payment will be deducted from the credit limit and the transaction will settle at a set time on a daily basis. Transactions that do not settle will be added back to the limit in 3-5 days depending on the bank.

It is easy to imagine all that can go wrong with this scenario. Fees for each authorization request in addition to the card holder's limit constantly being reduced by each request. Nobody wins except the gateways since they will charge for each authorization request.

Click & Pledge does not operate like this as nonprofits are often victim of hackers attempting to authorize cards.

We utilize our own internal algorithm to determine hack attempts and will decline the transaction without requesting authorization. If we determine a transaction is a hack attempt we simply decline it. This saves our clients a lot of money in authorization fees.

I hope you see why we do things a certain way. I can't possibly go into more details.

Please let us know if we can be of any further assistance.

[twoods]

Thanks for the detailed insight! Very nice and I completely agree with the way C&P is handling this.

I have "fussed" at other gateways that AVS really needs to be handled as part of the core decline at the bank's level. Meanwhile (in part because customers have instantaneous access to their accounts) it creates too much confusion and frustration for legitimate customers in the process of trying to prevent fraud.

-Tad