geev3s

[olive dagger]

I think the default behavior is expected here, since charging tax on an unverified tax ID might result in erroneous tax penalties (though I'm not a tax expert by any means)

[coral gulch]

hmm, that seems wrong to me... isn't the point of checking its verified/unverified status against a database is that you know whether to charge them tax or not? (a valid VAT number shouldn't be charged tax, but an invalid one should be?)

[olive dagger]

You said they're showing as tax_exempt, but now you're saying they were charged tax?

[coral gulch]

they're not being charged tax, and they're showing as tax_exempt.
I think this is incorrect because they have an INVALID tax id

if they have a valid tax id, they DONT get charged tax and are shown as tax_exempt (this is correct behaviour)

no tax id = taxed
valid tax id = not taxed
invalid tax id = not taxed (this seems incorrect to me)

[olive dagger]

As far as I can tell, that's the default behavior. If you think about it, it makes sense, because we can't attribute taxable funds to a non-valid tax id.

[coral gulch]

should we just delete the customers invalid tax id then if it's invalid? I think they should be getting charged tax if they don't have a valid VAT number (same as not having a VAT number)

[olive dagger]

How are you collecting tax id as of now?

[coral gulch]

via Stripe::Customer.create_tax_id()

saves to Stripe, Stripe then validates with VIES and returns the result via webhook

[olive dagger]

yeah, I would build into your flow a way to surface the status of the verification and reprompt the customer to enter valid a tax ID before creating payments in this case.

[coral gulch]

ok - the reason we didn't go for that initially was the reasonably long async VIES call from Stripe