#Wasabi-payments-capture

1 messages · Page 1 of 1 (latest)

rich stirrup
jagged flume
#

Hello @rich stirrup

#

We set capture to automating, but we send confirmation to manual, and confirm: false.

This combination turned out to be most optimal:

  1. We create Stripe Payment Intent and with that intent we create an order in our system
  2. During processing, order flow calls Stripe to try to "Confirm" given intent.
    2a. If confirmation works with no user interaction, Stripe would automatically capture the payment, and we grant the user virtual currency.
  3. If Stripe returns that additional actions are needed, we mark order "PENDING" and redirect the user using Stripe Client SDK to handle 3D secure, etc...
    3a. Once the user is done, we will re-invoke our API to "complete" the order, which would try to Confirm the payment again.
  4. If Order fails to process, we just "cancel" the intent before ever "confirming" it.
  5. In a rare case when the user requests a refund, or we have a system reason to return funds, we plan to take advantage of the refund API to refund the purchase.
#

Questions:

  1. Given the automatic capture approach flow described above, please confirm if the false config will always deliver the expected APIs as described in the above flow?

  2. Goal: The customer experience preference is to allow the customer to click on the “Buy now” button, when a 3D Secure challenge is required, it will redirect to the authentication page. At the same time, from the client-side, automatically capture the payment without having to redirect the customer back to the checkout page. On the server-side, once the user is done, we will re-invoke our API to "complete" the order, which would try to Confirm the payment again.

2a. As far as 3D Secure challenges, based on the "Test mode" the challenge always occurred within the iframe popup and never required the user to be redirected. When we are in production, do you suspect that there would be cases where the user is redirected completely away from our application where a redirect URL is required?

  1. How can we test if a return_url is required in test and production mode?
snow vault
#

Hey @jagged flume! Stepping in here and getting caught up

jagged flume
#

@snow vault THANK YOU

snow vault
#

@jagged flume why exactly are you using manual_confirmation here? Unless I'm missing something, this same flow can be accomplished with automatic_confirmation which is a much simpler flow.

jagged flume
#

@snow vault Basically in our system, an "Order" represents a financial transaction. If a user's account may get charged we need to have an order created prior to that, if later the charge fails, we would "Cancel" the given order.
In case communication fails anywhere between our system and Stripe, we would use the order record to attempt to recover.
This is why creating an asynchronous flow is non-trivial - if Stripe were to "capture" funds, but due to whatever reason, the order has to get cancelled, it's too late "not to capture" funds.

#

The order is submitted right before the user should be charged, and then the order system would have to determine if the capture should occur, or charge should be refunded. Adding a web-hook would break the synchronous nature of the order processing.
And if we were to capture funds before the order is created and only create and process the order after funds are capture (i.e. based on an event), there is a chance that order fails to process, therefore the user would not get virtual credits they have purchased, and we will have no record in our system to help us identify such case.

#

Would love to know if there is a better way to approach our use case here.

#

Or if the flow above works that is also great

snow vault
#

To confirm, there is no way to know about the success/failure of your "Order" before the PaymentIntent creation?

jagged flume
#

What would the flow look like with Stripe if we attempt to grant order first?

snow vault
#

Well you just use the normal automatic_confirmation in that case and you confirm the PaymentIntent upon creation, and if it needs 3DS then you handle 3DS client-side.

#

It would just not involve a final confirmation on your Server which is not really a recommended flow due to its limitations.

jagged flume
#

Got it. Thank you

#

Do you have any suggestions for 2a and 3?

snow vault
#

When 3DS is required, if you are using Stripe.JS to handle 3DS then by default we will always open a modal and we w redirect. You can optionally redirect yourself if you so desire by setting a return_url on the PaymentIntent. Take a look at our docs here for more info: https://stripe.com/docs/payments/3d-secure

#

Let me know if that doesn't answer what you are looking for!