#kmox83
sinful shell
The block rule is not properly activated, with the billing address it is, with the shipping address it is not
worn stone
Do you have an example that you can share that I can look at?
sinful shell
Block if :shipping_address_state: = 'KY'
worn stone
A PaymentIntent ID I mean
sinful shell
ah ok
worn stone
Where you didn't see the Charge blocked
worn stone
I don't see any rule set on that acocunt related to shipping address
worn stone
Yeah but I don't see that as ever being a block rule? I only see Allow if :shipping_address_state: != 'KY' related to shipping address.
Can you add the block rule and try again?
And provide that PaymentIntent ID?
sinful shell
we are trying workarounds, ok I can try
pi_3Oo6LuGkpJdPmTgB0QegYKFB
It looks like it is not working when there is a digital and phisical item in the same payment link
we have created a new payment link with only a physical device and the block works
worn stone
Looking
Hmm yeah that looks like it should have been blocked
Give me a few to look deeper.
white irisBOT
worn stone
Okay sorry for the delay @sinful shell, we've been able to reproduce this as well and it does look like it should be blocked in both cases. We are filing a bug report internally to get that fixed. The best next thing for you to do is to write into our Support team via https://support.stripe.com/contact/login with the details of what's happening, then they can keep you updated on that bug fix.
worn stone
@sinful shell to be clear, the difference in behavior here is payment versus subscription mode for your Payment Links. With payment mode the Shipping address is carried down to the PaymentIntent so it is assessed with Radar, however in subscription mode the Shipping address is associated directly to the Checkout Session and the Invoice, not the PaymentIntent, so it isn't taken into account with Radar.
As noted, we will report this internally for consideration of whether it should also be added to the PaymentIntent in subscription mode
Looking at this a bit more, I don't actually think this will happen really.
The Subscriptions API doesn't support carrying Shipping down to the PaymentIntent level.
So it isn't really possible and thus why you see this behavior.
So mostly I wouldn't rely on a Radar rule around shipping address for a Subscription mode Payment Link.
sinful shell
Thank you for the information and for the detailed explanation
We are doing this because we are not aware of any other way to prevent sales to a specific state of US
(using payment links)
worn stone
What is wrong with blocking based on the billing state?
Ah because it doesn't collect state for billing address here, right?
sinful shell
that we are not allowed to ship there, if they would buy in another state they would be able to ship in KY
it does and the blockage works with the billing address
worn stone
Ah wait yeah we do force full billing address collection
I see though
You specifically want to block shipping to a certain place.
worn stone
Gotcha yeah you really need a custom flow to best handle this... I think the only option if you are going to rely on Checkout would be to actually collect the shipping address before you redirect to Checkout.
Which if you are using Payment Links is pretty difficult
Since I assume you are actually sending the link in this case, not having the customer come to your site.
sinful shell
ok in future we will use a custom flow, for now we will mitigate by blocking the billing address
worn stone
Yeah unfortunatley no other way at the moment.
sinful shell
Thank you for the time spent on this!
worn stone
I think the other thing you could do is add a consent_collection.terms_of_service to your Payment Link where you state that you can't ship to certain state(s) and if those are selected then the purchase will be refunded. Will be a little strange as the option for that state will still appear in the dropdown, but best I got right now.