#hamid-sepa

1 messages · Page 1 of 1 (latest)

sick comet
#

@tawny minnow hi! well webhooks are really not optional here. It can take 14 days for the charge to finish processing, are you going to poll all that time?

In any case Stripe::Charge.retrieve(payment_intent_id) will just give you an error because you're passing a PaymentIntent ID to the Charge API so that doesn't work.

If you want to poll you'd retrieve the PaymentIntent and check the status of that object.
https://stripe.com/docs/api/payment_intents/retrieve
https://stripe.com/docs/api/payment_intents/object#payment_intent_object-status

tawny minnow
#

yup, ill keep pooling once a day

#

hmm okie

#

so one question

#

Stripe::PaymentIntent.create

#

this will create payment_intent, which means it will charge the sepa account

#

right?

sick comet
#

no, the charge happens when the PaymentIntent is 'confirmed'.

tawny minnow
#

basically for ach accounts we do Stripe::Charge.create and for sepa and credit card we do Stripe::PaymentIntent.create

#

am I right

sick comet
#

yep!

tawny minnow
#

and when we will do payment intent we wil have to get it

#

via retrieve payment intent api

#

in pooling

sick comet
#

as I said last week I think, unfortunately ACH and SEPA are completely different integrations entirely right now with completely different code you'd write 😦

tawny minnow
#

i am implementing both

#

rather all three

#

cc, ach, sepa

#

so again my question

#

basically for ach accounts we do Stripe::Charge.create and for sepa and credit card we do Stripe::PaymentIntent.create
am I right

#

and when we will create payment intent we will have to get it via retrieve payment intent api in pooling

sick comet
#

well I wouldn't say 'basically' since they are completely different and like I said, creating the PaymentIntent doesn't actually charge anything, but yep!

#

it's not as simple as just saying Stripe::PaymentIntent.create is equivalent to Stripe::Charge.create with a different name, because that's not true, it is a completely different style of integration.

tawny minnow
#

i got your point

#

but in terms of process, is there anything left after creating payment intent

#

to charge client

sick comet
#

yes, confirming the PaymentIntent.

tawny minnow
#

so if payment_intent is succeeded in case of cc or sepa

#

it means client is charged

#

right?

sick comet
#

if it is status:"succeeded" then the payment is complete and the customer was charged, yes

tawny minnow
#

thanks 🙂

tawny minnow
#

one last question please

worldly tulip
#

👋 hi, go ahead

tawny minnow
#

if status == 'failed' for charge api, we get failure_code and failure_mesage

#

attributes

#

will those be same for payment_intent api as well

worldly tulip
#

similar, and payment intents have charges under the hood (see the charges attribute in the api spec)

#

but can you share an example?

tawny minnow
#

i think for sep there isn't any thing like status=='failed'

#

right

#

?

#

when payment_intent is involved, there isnt any status like failed

#

see this

#

so it might be canceled

#

this is so much confusion

#

in above document statues are as mentioend and on other page its written this

#

payment_intent.payment_failed The customer’s payment was declined. Contact the customer via email or push notification and request another payment method.

worldly tulip
#

Right, you can request and supply another payment method for the payment intent

#

i expect it would revert to requires_payment_method status

#

and you can then confirm with a new payment method

#

this is the advantage of payment intents, you can try again

tawny minnow
#

didn't get, see in pooling i'll retrieve payment_intent

#

then what status ill get from it

#

failed, payment_field or canceled

#

for Stripe::Charge.retrieve(stripe_charge_id)

#

i check like

worldly tulip
#

what do you mean by "in pooling"? oh polling

tawny minnow
#

stripe_charge&.status == 'failed'

#

ohh, yea

worldly tulip
#

yes, it will work different

#

you should instead listen to the webhooks for payment_intent.payment_failed

#

but you can poll and check for requires_payment_method vs succeeded if you prefer

tawny minnow
#

i need failed scenario

#

webhook is not fisible for us

#

we have mor ethen 100 subdomains and can increase gradually

#

so for failed case what status, ill get in payment_intent

worldly tulip
#

that's fine, webhooks can still work, but aren't strictly required here

#

like i said: requires_payment_method -- the charge/payment fails, so you need to provide a new payment method to try again

#

payment intents are stateful, they don't have a terminal "failed" state. you can retry until success, or you can cancel them.

tawny minnow
#

so you mean status will be requires_payment_method

#

if it failed

worldly tulip
#

yes

#

if the underlying charge/payment failed the payment intent will revert to requires_payment_method yes

tawny minnow
#

okie great, just to be on safe side, let me reiterate.

#

For Charge Object status could be failed
But for PaymentIntent api status must be requires_payment_method these both are failed cases

worldly tulip
#

in the failure scenario you describe the payment intent would revert to requires_payment_method, it isnt generally a failure case

#

eg: if you have a new payment intent without a payment method, it's also requires_payment_method (and it has never has a failed payment)

tawny minnow
#

but if status changes to requires_payment_method after processing which is initial state, we can consider it fail

#

just for our assumption, as this will require

#

user's/client's input again

worldly tulip
#

yes, for your scenario that's right