How to verify Billing Address in Payments API?

[jplehmann]

We want to process payments from buyers to sellers with us being a 3rd party on our website. The Payments API seems to achieve this and even allow us to take a small fee.

However, it is very important to our sellers to make sure that there is a match between payment/billing address and the shipping address. It looks like Square won’t tell us the address associated with the card, however we can ask the customer for their billing address and pass this into the Create Payment API.

What happens then if we provide that address? Does Square compare the full address or the zip code only against the one associated with the payment – and then give some kind of error if they do not match? This way we can know that the Customer gave us a legit address, and we can pass that along to the seller and they can decide if it’s close enough to the shipping address for their comfort?

• We saw ADDRESS_VERIFICATION_FAILURE - The card issuer declined the request because the postal code is invalid. - does it mean it doesn’t match? or just is bogus?
• We also saw this post about VERIFY_AVS_FAILURE, so is that what would occur?
• We saw risk level comes back in the response, but it is very vague and would prefer to know specifically about the address.

Also, is there any benefit if we pass in the shipping address also to the API?

Thanks for helping us to understand how we can use this API safely.

[Bryan-Square]

Currently ZIP or postal code matching, also known as the Address Verification System (AVS), is what is sent to the card network and is a factor that our fraud prevention models consider when assessing risk. Based on seller feedback, we found that rejecting payments based on AVS mismatches alone ended up declining an unacceptable number of good payments. When our fraud detection models analyze a payment, they take a number of factors into account to determine if the ZIP code was either unintentionally mistyped or if it was a fraudulent transaction. If the data points to an unintentional mistype, we’ll approve the payment; if it appears fraudulent, we’ll decline it.

If any additional address verifications is needed for sellers to determine if they’d like to ship to a customer it would need to be a feature of your application since Square doesn’t validate that information. You can use our APIs to collect that information however validating it would need to be a function of your application.

[jplehmann]

Thanks @Bryan-Square :

You can use our APIs to collect that information however validating it would need to be a function of your application

To be clear, what we need to compare is the payment address (assoc with the card) to the shipping address (which we can collect). Our vendors will not want to ship to an address that is not the same as the card. Or they might ship to the hub located by the payment address. Can you tell me how we can access the payment address with APIs?

We now see that the billing address is part of the Payment object, but I assume this is just the value which WE sent into the API to create the payment, so it’s not adding value.

Thanks

[Bryan-Square]

Currently there isn’t a way to get the address associated to the card making the payment unless you collect it. That information isn’t required when processing a payment.

[jplehmann]

@Bryan-Square that’s what I’m trying to understand then… You said “You can use our APIs to collect that information however validating it would need to be a function of your application”.

So what information can I collect from your API? It sounds like I cannot collect what I need in order to do the validation. Do you understand our confusion?

Either, I need Square to tell me the payment address (or zip) so my app can compare it to the shipping address…

Or, I need to be able to get an address from the buyer (like billing address), and give it to Square and have Square validate it for me. That was where I had started the conversation, but it is unclear to me how the validation on Square’s side works. I don’t see why it would be difficult for Square to just return an attribute that tells us if the address or postal code from the supplied billing address matched the payment address. Instead right now, we have to go off a “risk level” of low/med/high? So we have to assume that medium means it didn’t match? Please clarify.

Thanks!

[Bryan-Square]

You’re right, you can collect all the information from the customer however there isn’t anything within Square that does an address check other than the AVS check when a card is being processed. Square doesn’t get the address associated to the customers card from the card network.

If your customers are going to ship within a certain area you’ll need them to define the areas they will ship too. Then when you collect the shipping information from their customers that are making the payment your application will have to verify it’s within their defined area.

[jplehmann]

Thank you for your prompt replies.

As far as I can tell, the ONLY benefit we are getting is the AVS check. So I need to understand more about AVS because it’s the only thing ensuring that the billing address which we collect credible. If AVS check doesn’t do what we expect, then we are deceived into trusting it.

Earlier you said:

Currently ZIP or postal code matching, also known as the Address Verification System (AVS), is what is sent to the card network and is a factor that our fraud prevention models consider when assessing risk.

If AVS is something that Square is “sending”, then Square must have the billing and payment zipcodes to compare, right? But you just said that Square does not have the payment address info, so how is this possible?

Based on seller feedback, we found that rejecting payments based on AVS mismatches alone ended up declining an unacceptable number of good payments. When our fraud detection models analyze a payment, they take a number of factors into account to determine if the ZIP code was either unintentionally mistyped or if it was a fraudulent transaction. If the data points to an unintentional mistype, we’ll approve the payment; if it appears fraudulent, we’ll decline it.

I wonder how you guys can do this if you don’t have the payment address?

@Bryan-Square

If your customers are going to ship within a certain area you’ll need them to define the areas they will ship too. Then when you collect the shipping information from their customers that are making the payment your application will have to verify it’s within their defined area.

The issue isn’t so much the areas my seller will ship to, but that the shipping must match the payment address.

As much as I appreciate leaving a trail here for others to read and learn from, I feel like in 10m on the phone I could properly understand this, and I’d be happy to come back and write up a summary.

[jplehmann]

Follow up question:

@Bryan-Square

If the data points to an unintentional mistype, we’ll approve the payment; if it appears fraudulent, we’ll decline it.

So if AVS fails, and you still approve the payment, will the response or any API data we have access to indicate that AVS failed? Because in our case we would actually prefer to fail this.

I am going to be running millions of $ for thousands of our customers, so this is a pretty significant thing for us.

[jplehmann]

Looks like similar concerns over here:

CVV and AVS returning as NOT_CHECKED

We are using the PHP SDK. The form displays a field for postcode and cvv, however the return we receive is CVV_NOT_CHECKED and AVS_NOT_CHECKED. How can we force the API to check for both and not process payment if either fails?

[jplehmann]

And more related concerns here:

Square Payment How to validate postal code. Currently Postal Code is not...

You guys have such a great platform, but it feels like withholding details and/or overriding bad postal, zip and cvv failures is a real weakness. Why not expose these details so API consumers can make choices appropriate to their platform? Because, our customer are the ones who are going to have to eat the chargebacks.

Here is a quote from one of my customers who doesn’t use Square for this reason – or requires their customers to call them on the phone, give credit card details, when they enter in by hand (paying a higher fee) to make sure things match.

Square has an invoice feature which allowed customers to enter their own payment information and I liked it bc I never had to handle any of it.
This was also nice because I believe you can do payment plans as well so they pay on the invoice progressively.

Sadly this ended up in a scenario where I could never trust the shipping information that they provided and got burned by someone using a stolen CC.
Had I gotten the credit card info I could have then compared it to their shipping info (completely different states/ends of the country) and asked more questions.
As such since that point in time I only take credit card directly and then manually enter the information in myself into square which is comically at a higher rate even tho it’s less likely for fraud.
This is my top concern with any approach using square and their more applicable invoicing feature, how to provide this or similar protection through (my platform) if it uses invoicing on Square.
Matching billing and shipping addresses (we only ship to hubs by the address for billing unless we know them)

[Bryan-Square]

I wouldn’t rely on AVS checks. I’m trying to understand what you’re trying to solve for? If you worried about fraud I’d recommend using Risk Manager and 3D Secure for the payments. You can set rules and verify the buyer.

[jplehmann]

@Bryan-Square thanks for the offline clarifications. I understand that AVI isn’t useful because this is a feature of the card/banks which is not very well supported, so it probably wouldn’t have good coverage. However, this seems to contradict online documentation where address comparison seems to be a central strategy of the risk manager?

Regarding 3DS, I understand this is a service our seller could enable. However, when I look at this system, I wonder how it could work in the United States. I don’t believe I’ve supplied those 3 types of information to my credit card company, so I don’t see how they could know the correct answers to the questions which I am asked? I could see how this could work in Europe where it’s required, so all the banks have that information. However, if this IS effective in the US, can you verify if there are guarantees such as protection against chargeback from cc fraud?

Second, I see that in 3DS/SCA, postal code is requested. Is that always requested or just with 3DS? If postal code is given, is this given back to us through the API so that we can use it as a location value that has been validated to some extent?

Regarding Risk Manager, I understand that my sellers can enable this, and then they can make the verification process which occurs in the create payment more secure.

I found in one place that it said if we provide the billing/shipping address form the user it can help the risk manager? Can you speak to that?

However, throughout the documentation, it has statements like these telling us that the merchant should themselves verify that billing and shipping information match.

That is very concerning, because it takes us back to the very beginning of this conversation. That is exactly what I was asking about, and also trying to avoid. For, how are we supposed to do this? This requires that we have the buyer send the seller a photo of their credit card, and a large part of using Square is to prevent this kind of insecure activity.

Ugh I feel like I have more questions than answers again. I’m sorry…

[jplehmann]

Any updates here? It’s been 10 days.

[Bryan-Square]

@jplehmann, I guess I’m confused at what you’re trying to accomplish. Are you looking for a Square provided way to guarantee the shipping address is in fact the address that’s associated to the card the customer is entering. If so that’s not possible.

Also customers have the ability to enter a shipping address that’s not associated to the customer that’s making the purchase at all. This may happen when they purchasing a gift to someone and sending it directly to them as one example. We have thing like Risk Manager that help verify the buyer and mitigate fraud behavior but we don’t have a way of verifying any additional information other than what’s documented. Let me know if you have any additional questions.

[FDPH]

I would also second this request, i have used other payment providers and this was avaiable via there api.

Simply put, the postcode the user submits as part of the card request form, we need to be able to access this via your API.

If you are capturing it, it shouldn’t be difficult to return this as part of the API request.

[Bryan-Square]

The postal code the customer submits in the form is available in via the API. When you tokenize the card you can get back card details from the tokenize call.