released stripe payment

carlptaylor

hi

I was checking some stripe payments, and noticed that one of the payments had been released, this seems to indicate that it was refunded to the customer.

I have no knowledge of returning the payment via brickowl as the package was sent, but I did take a little time to deliver the package.

I didn't see anything prior to signing up for stripe that a time limit is imposed, but I see now a message is displayed for all stripe orders, to remind us.

In this instance the customer has received quite a number of parts, I received not favourable feedback and I'm out of pocket ....

anyone else had issues with stripe ?

minithingsforlife

Stripe has a time limit of 7 days from Authorisation to Capture. I am sure it is in there T&C's.
Brickowl uses the Authorisation and Capture system where Bricklink just captures immediately after payment is made.
However I also got caught out on this previously. But now Admin has added a warning message at the top of orders paid with Stripe

carlptaylor

I asked stripe about it, and it seems it's a brickowl.com issue.

From stripe "When someone makes a purchase, the charge is authorized, and then it is captured. If the capture does not take place, after seven days the authorization is released. That is the meaning of what you see on the line that says released. What you can also see is the code 400 ERR indicating the capture event failed.

This type of setup is not the default setup for a Stripe account, so I would reach out to Brick Owl and discuss this with them if you wish to change it."

Nothing I can do about the released payment/free parts, but if the above helps someone else .. all good

unbrickable

Thx for this information. Just a question, @lawrence why is the payment captured on shipment date and not on de order date

Colorado Bricks

You can capture it before the order is set to "shipped'. Go in the stripe dashboard and look for the pending transactions.
I do capture it before shipping in some occasion, like if don't want to capture the full amount. BO will show a Stripe error when order is set to shipped, but it has no consequences.

Lawrence

That's interesting to hear Stripes response. We use the authorise and capture model as I believe that to be the standard among online shops, whereby you don't actually charge the customer until you ship the order out. In retail stores, where the item is handed over to the customer, they would capture payment instantly. I would of course be interested to hear if other people have different views on this.

minithingsforlife

I know that bigcommerce, on of the top 3 e-commerce platforms do not use the authorise model. They just capture straight away.

Colorado Bricks

Usually it is captured when the order is being worked on, that is how S@H and Amazon work, not when shipped.
If the capture would be on the "Processed" stage I would feel more comfortable.
When it is a large order, I always capture the amount before shipping to protect my self against a failed capture after I have shipped the items (as I set the order to shipped after I mail it)

DadsAfol

Interesting point. I know with PayPal auth/capture we've never had an auth that failed to capture. I think that would be pretty rare as the auth actually "holds" the funds on the buyer's card. So the only way I could see a capture fail would be if the cardholder reported the card lost/stolen after the auth and before the capture.

I would support a move of capture from "shipped" to "processed". For us the only difference is that the mail carrier hasn't shown up yet.

Also, while we are on this topic, we really need the capture to be reduced for any refunds initiated pre-shipment. Both PayPal and Stripe would allow you to capture less than the original auth amount. Right now, if we are missing a piece and need to refund, we literally have to "ship" the order, then process the refund.

It would make much more sense (to the buyer) to just reduce the capture amount. In an extreme dollar example, you might end up holding the buyers funds for 5 business days until the refund posts through to the buyer's bank, which is a little unfair to them. For example, a buyer buys two copies of a $100 set so their card is authed for $200 and that is "held" in their bank account immediately. If the seller made a mistake and only had one copy (and agrees with the buyer to continue the order for one), currently BO would capture the full $200, then issue a refund for $100. The buyer would not get their $100 "released" until they receive the credit a week later. So to the buyer's perception the seller took and held their $100 for a week. That is not very buyer-friendly.

budgetkids

The majority of places we shop online capture right away.
My work captures upon shipment of the order (major cell phone company)

We go into stripe and capture everything immediately and always get the BO error about how it can't be captured (because we already did)

We would prefer the auto capture method as soon as order is placed.

Thank you,
Chris

Hoddie

I prefer it the way it is now. Much cleaner if you need to do a (part-)refund, the alternative being that you take the full lot immediately and then the customer has to wait 14 days to get the refund.

Colorado Bricks

@DadsAFOL when this happens, I manually capture the amount in Stripe as it let us capture less than the amount paid.

carlptaylor

Personally, I think capturing at the time of order as BO does for paypal is the best way, if a refund is required this would be processed at the time of shipping, as we would do for paypal payments, in this way we always know the funds are at on their way.