Using

solidus_auth_devise

we would like to require users to confirm their email address if the order total is below a certain amount before they can check out as a fraud prevention measure (lots of fraudulent orders on the cheapest items in the store). We have this part working with some monkey patching, but noticed if the user registers an account during check out, once they confirm and log in, their cart is not associated, so they login to an empty cart. Found the setting

allow_unconfirmed_access_for

which does let the cart associate but then allows the user to check out without confirming their email first. Is there any way to associate the cart immediately upon account creation without letting a user check out while unconfirmed? Or maybe block checkout from fully completing if the user hasn't confirmed their email yet? My initial thought is that maybe the latter might be easier to implement. I found some of the logic in the

warden

and

devise

gem, but wondering if anyone has worked this out already or if there's a different setting I'm missing. Edit: Maybe this actually isn't working. I can't reproduce it in the normal checkout flow, but after deploying this yesterday, somehow over 12 guest orders have still come through that should have been forced to register. Not sure if there's some other way these might be coming in? Hoping anyone has any insight. Edit 2 (sorry): Looks like the method I took is only blocking the frontend form from appearing, so hitting the

/checkout/registration

endpoint with a valid auth token and the email field filled out still allows a user to guest checkout. Not sure if we did this wrong or if this is a bug.

Would love if anyone's able to provide any input/ideas on this. Willing to pay for help too if necessary. We have a client that's getting 40+ $10 fraud orders a day right now because there's no built in way to force any sort of account validation, these orders seem to be avoiding the frontend checkout process some how. Rackattack/Cloudflare aren't able to block them since they're switching IPs

What about requiring manual capture by an admin on the order if it’s below a certain amount?

Looks like for all these they're using the Braintree payment method, supplied by the

solidus_paypal_braintree

gem

Requiring manual capture wouldn't be ideal (since that would probably annoy too many regular customers), the route we were hoping to go would be to add some sort of backend check that prevents a user from placing a low $$ order if they're not signed in with a validated account

to add some sort of backend check that prevents a user from placing a low $$ order if they’re not signed in with a validated account

I think you can do that with a new before_transition in the order state machine: https://github.com/solidusio/solidus/blob/c09ead361b6b705897bf6a05aa38cef24d7d3c0d/core/lib/spree/core/state_machines/order.rb#LL114C60-L114C60

Okay cool that's where I was at with my last attempt. Was able to conditionally add one of these, and it will do it's check and run, but couldn't seem to figure how to block the transition from occurring? Tried a few things in

require_registration

but haven't found anything that actually works (think I grabbed this from another method).

Are you sure this is executed, seems correct to me

If I throw a `binding.pry` in there it does seem to throw me to a console.

this is another method where it’s working: https://github.com/solidusio/solidus/blob/c09ead361b6b705897bf6a05aa38cef24d7d3c0d/core/app/models/spree/order.rb#L481-L487

Just added a binding.pry in that method now, and tried it out. It does trigger, and I can see the errors get added to

errors

but when I exit the pry, it just moves on to the address step anyways. Are

errors

the condition that should prevent it from moving forward in the state machine?

I think it’s more the return false that blocks the transition

Okay that's what I thought and then the UI can just show the errors.

let me check the documentation on the state machine gem

I'll try that.

can you try to move the transition to another step?

Interesting...

maybe it’s still in cart?

I moved it to

base.state_machine.before_transition to: :confirm

and it threw me back to the delivery step when I tried to continue.

yeah, because the order is still in the previous state before calling

order.next

I see. So how would be the best way to handle this do you think? Definitely don't want the user to have to enter a bunch of information before finding out they need to register. Should I conditionally add a checkout step before address?

one thing you could try is to manually move the order in the address step before rendering, in the checkout controller, like

order.go_to_state(:address)

.

Okay this gives me some ideas to start from and at least I understand a little better what part is not working to reassess. I think the other problem and part of the reason I am avoiding letting the user enter anything (address etc) before making them register, is that unless we allow unconfirmed access for some period (which defeats the whole purpose I think since they can check out), they lose their cart when they register and sign in. May not be a huge deal since looks like most customers are not doing this, but trying not to inconvenience more than necessary.

Let me know of this goes!

Wound up moving the logic to the checkout controller and tweaked a little bit and it just works. Wound up just leaving the "allow_unconfirmed_access_for" setting of devise off for now, since it was causing a view/route error when users clicked the email confirmation link for some reason. Works fine with it off.

So this didn't help much because then they started to use burner emails they could validate with. We just noticed a ton of these are using the same address, which leads me to believe Braintree's AVS is not happening, even though it's all turned on in the Braintree account web portal. Could there be something that needs to change on the gems end?

Looks like you can configure rules in Braintree for these failures - https://developer.paypal.com/braintree/articles/guides/fraud-tools/basic/avs-cvv-rules. Lots of cards will fail AVS for valid reasons, so you probably don’t want to block all transactions.

Thanks. Opened a ticket with Braintree. Hopefully they have some ideas to help. This stinks, there has to be a way of dealing with these without affecting regular customers so much, we've never ran into this with other shopping cart platforms so this is a first.

To be honest, I don’t think it depends on the platform, but if we discover we can do anything better, we are open to improve Solidus to be more safe.

Agreed with @kennyadsl, fraud is something most large online stores have to deal with. You’re dealing with a sophisticated attack that’s adapting to the blocks you’re putting in place. It’s a cat and mouse chase and you just have to make it not worth the attackers time to go through the hurdles you’ve put in place and they will move on to another target. The store I work on gets a lot of attacks, from distributed credential stuffing attacks, to card testing and so on. Some inevitably succeed, but we manage to block most of them. I would recommend adding some rudimentary fraud checking rules in your store that prevent an order from going to fulfillment and requires a manual review step if anything gets flagged. You can start by adding a few basic rules, like orders from different customers going to the same address, multiple failed payments, small amounts, etc. Alternatively you can integrate a 3rd party solution for this like Signifyd, but they tend to work on a percentage of the order total for all orders, so can get pretty expensive.

Do you know why we might be seeing this now with every transaction attempt that's not using an already stored card?