#Mike-cards

1 messages · Page 1 of 1 (latest)

near matrix
#

you'd have to customise your integration a bit since it's not how we usually recommend integrating but yes

prisma mulch
#

Hi there

near matrix
prisma mulch
#

I should add that I'm using a SetupIntent to put someone's card on file

near matrix
#

but I personally would just ask the customer where they live and not rely on the card data since for example maybe I have a FR card from my bank that I sill use but I moved to the US

prisma mulch
#

The only way I can see of doing it at the moment is to go through the process of using a PaymentElement to get their details, create a SetupIntent, and check the card region once that's all happened. If it's not the same as the user's region, I'd have to remove the payment method.

#

I notice that Stripe seems to understand that I'm in the UK when it asks for my credit card detail however, as it asks for a Postal Code, rather than a ZIP code.

#

Is there any way to validate the credit card form before it is submitted to Stripe for processing? Or is that a security nightmare?

near matrix
#

anyway it's impossible to do this with the PaymentElement specifically

#

all our integrations by default are "create intent -> confirm client side -> get result" and you can't see the card details before they're used in the intent

prisma mulch
#

Okay

#

How does Stripe know which region a user is in when it presents the credit card form? If I can be sure that a British customer will always be asked for a Postal Code, I can be reasonably sure that they won't be able to register a US card, for instance.

near matrix
#

we look at the BIN

#

you don't get access to that sort of information I'm afraid

prisma mulch
#

BIN?

near matrix
#

what I said above(use an integration where you create the PaymentMethod and then confirm the Intent separately) is the only option

near matrix
#

in fact we don't even do that any more, since it's not accurate

prisma mulch
#

So you don't have the number yet

near matrix
#

yep because the PaymentElement just looks for the geo ip of the user

prisma mulch
#

I presume the form is looking at the browser time zone or something?

near matrix
#

but other elements like the CardElement use the BIN

prisma mulch
#

So presumably I can fool it using a VPN then

near matrix
#

probably!

#

and like I said, BIN lookups are not 100% accurate either

#

so like I said, I've never heard of this requirement you have

prisma mulch
#

Okay. Thanks for all the great info. I need to go away and think about all of this!

#

"Distributor shall ensure that each End User holds a valid account and
that prior to the Resale, the End User has submitted information that
enables the principal place of residence of the End User to be
determined by Distributor to ensure that the Digital Audiobook is not being sold outside a Permitted Territory. To ascertain this Distributor
will verify that the credit and/or other payment card address registered
to that End User is in a Permitted Territory for that Digital Audiobook,
and in the event this criteria is not met Distributor will not conclude the
Resale."

naive cloud
#

in general, the card => country lookup doesn't always map perfectly onto where the customer lives, or even where eg: their bank branch is

prisma mulch
#

With regards to the above, is the region on the card the issuing region or the customer's address?

naive cloud
#

it's the issuing region

prisma mulch
#

So it's the Billing Address country I need to look at then presumably

#

And I can use the "Zip Check" to make sure they've entered it correctly?

naive cloud
#

without wanting to give any particular advice, especially legal advice, you might want to consider whether your goal here is to actually prevent people from a different region from purchasing an audiobook, or to scrupulously follow a set of compliance steps so that you can say that you're meeting the requirements set by the partner (without regard to whether or not following those requirements actually prevents people in a different region from purchasing audiobooks)

prisma mulch
#

That's a good point

#

In any case, it's the mechanics I need to understand right now; I can make the business call later...

#

Since I can't get the details from the PaymentElement, I think I need to go through the process of setting up the payment method, then inspecting it using your API to find the Billing Address country and verifying the ZIp Check has passed. If that matches the territory the user is in, I can keep the payment method. If not, delete it and ask them to enter another.

#

Which might be annoying for them!

#

Does the Zip Check verify that the Billing Address is the same as the issuing bank has on record?

naive cloud
#

a lot of banks verify the zip/postal code, and nothing else

#

people's addresses can be weirdly structured, and a fun way to sidestep this problem is to only validate the part of the address which is a well-structured number

prisma mulch
#

So, given all of the above, what do you think is the best approach to achieving a reasonable degree of compliance with the requirements? (I appreciate you can't give legal advice; I will get some from my lawyer!)

naive cloud
#

I don't think I can really answer that question for you. the data points that you can validate are that the billing address matches the bank's records (which often only really means that the zip/postal code matches, and some banks will give you an inconclusive answer to this question anyway), where the card was issued (and this is sometimes a little bit disconnected from where the customer actually lives), and the customer's IP address (which can be circumvented in any number of ways). you can validate any or all of these, but it's never going to be perfect.

#

I still think the first order question here is whether this is a results-oriented problem or a process-oriented problem

#

what does your counterparty in this arrangement actually care about?

prisma mulch
#

The counterparty here is a publisher and they want to make sure I don't sell audiobooks in the wrong territory.

#

The exact reasons for that I don't know; perhaps agreements with authors. In the end, it's all about enforcing copyright I guess

#

I think I just need to show that I'm doing something to honour the spirit of the agreement. I don't think perfection is important.

#

As you say, there are a number of data points here I could validate. And a spectrum of compliance, from none to validating all the data points.

#

I think that the Stripe form already presents a great first hurdle, in that the customer will be forced to put in a Zip/Postal Code, which already separates my clients into Uk/US, which is 90% of the battle.

#

Let's leave it there; thanks again!

naive cloud
#

sg!

prisma mulch
#

Sorry, one last question

naive cloud
#

and yeah, my naive assumption is that if a customer in the UK buys an audiobook with a credit card issued in the US, that's a pretty defensible thing to let slip through

prisma mulch
#

If a user punches in an invalid Postal Code, I assume the payment method will still be setup in Stripe, and fail the Zip check?

naive cloud
#

there are a couple of possible outcomes

#

the bank might decline the validation auth altogether, which would return an error when creating the PM

prisma mulch
#

Right.

naive cloud
#

or they might not be checking the postal code, in which case the PM would be set up successfully with address_line1_check/address_postal_code_check = unavailable/unchecked

#

or they might still approve the validation auth, but tell you the zip was invalid, in which case you'd get back failed for the result of the check

prisma mulch
#

Caramba, many variables to deal with

#

Okay, I'll go and run a few different scenarios and make a call. I'm starting to think this is largely unenforceable in a practical way in any case!

naive cloud
#

I mean, it's possible to circumvent

#

but it's possible to circumvent anything - just a question of how much effort is required

prisma mulch
#

Yup

naive cloud
#

no matter what you do, it'll always be possible for me to phone up a friend who lives in the UK and ask them to buy an audiobook for me

prisma mulch
#

Is it possible to use the Fraud Detection rules to implement this?

#

Block if postal code verification fails

naive cloud
#

yeah, you could get radar to do that part of it for you

prisma mulch
#

OKay, great

#

Is Radar an add-on or part of the basic package?

naive cloud
#

iirc, that part of radar is free

#

normal radar is free (unless you have custom pricing, in which case it's split out & billed separately). radar for fraud teams costs extra, but you don't need RFFT to use the built-in zip check rule

prisma mulch
#

Yup, found it, thanks

#

Hmm, didn't seem to work

#

I've switched on Block if Postcode verification fails rule

#

Then used test card 4000000000000036

#

"The address_zip_check verification fails. If your account is blocking payments that fail postal code validation, the charge is declined."

#

Do those rules apply to SetupIntent?

#

Or only kick in once I try and put a charge through?

#

I've managed to add the payment method to my customer and I can see that the Zip check failed...

#

@naive cloud ?

naive cloud
#

I can't recall whether those radar rules run on testmode charges

#

I want to say that they do not, but I can't find documentation one way or another

#

the rules should run on either creating a charge or attaching a card to a customer, though

prisma mulch
#

Actually, maybe I can just test with my own Debit card in Live mode?

naive cloud
#

you're not really meant to do that sort of testing with real cards

#

it's forbidden by the stripe tos and the visa/mastercard network rules

prisma mulch
#

Oops! Thanks for letting me know.

naive cloud
#

no worries 🙂

prisma mulch
#

How do you switch to Live mode; different API key?

naive cloud
#

yeah - you have separate keys for live/test mode

prisma mulch
#

Thanks