#durrell-issuing-settlement
mental ravine
vocal jay
If you set capture method to manual you need to explicitly capture the PI: https://stripe.com/docs/issuing/testing?testing-method=with-code#capture-authorization
idle glacier
Ahh ok.
So typically the capture would happen right away at something like the kiosk at a grocery store?
vocal jay
Yeah
Default behavior is to capture on confirmation though
You explicitly enabled manual capture by setting capture_method='manual'
idle glacier
on a connected account that would be like this right?
Stripe::PaymentIntent.capture(
{ id: intent.id },
{ stripe_account: stripe_account_id }
)
That looks right
Although I don't think you need to explicitly type 'id': https://stripe.com/docs/api/payment_intents/capture?lang=ruby
I think you just provide the string
idle glacier
If I only pass in the string as one argument I get this error: No such payment_intent
I usually will get that error when I'm looking up a record for the wrong account.
When I created the PaymentIntent I passed in the stripe account so I figure to retrieve the Payment Intent I need to pass in the stripe account as well especially since I'm getting this "No such payment_intent" error.
vocal jay
Can you share the request id
You do need the stripe account header
What I meant by my previous message is you probably need to do this instead:
{ intent.id },
{ stripe_account: stripe_account_id }
)```I get a ruby syntax error when I do that
and response is nil when I do this:
client = Stripe::StripeClient.new()
response = client.request do
Stripe::PaymentIntent.capture(intent.id)
end
puts response.request_id
ya, is it safe to send the payment_intent id here of a live mode payment intent?
vocal jay
yes
idle glacier
pi_3Ma2BiQs8t94ZQUF1pSoch9A
vocal jay
That PI has already been captured
Why are you trying to capture it again?
It's in a status of succeeded
idle glacier
the status of the authorization is still "pending". The request_id to retrieve the authorization is: req_xy7F91AlT4AJLO
vocal jay
That Pi wasn't created with manual capture
No need to capture it
The auth is also approved
idle glacier
yes the auth is approved, but it's status is still "pending".
vocal jay
I do see status pending for some reason though
idle glacier
This says it has to be captured in order for the rest of the flow described here to continue: https://stripe.com/docs/issuing/purchases/transactions
so if it was captured I would expect the status of the authorization to be closed instead of pending.
idle glacier
No worries. It would seem that since the PI succeeded that the authorization should be captured though.
vocal jay
Ok let me ask a colleague about this
broken spear
👋 @idle glacier ! I'm taking over
My understanding of Issuing is that this is all expected. The Issuing Transaction will be created later, async, often hours later. At this point the funds are held (the Authorization represents that) and the merchant (where you created the PaymentIntent) can totally decide to over capture, or refund later, etc. So in a way the "clearing or settlement" happens async, usually delayed (it simplifies things if they decide to refund them quickly for example.).
It's what we cover at https://stripe.com/docs/issuing/purchases/transactions when we say
After an authorization is approved and is captured, the status on the authorization is set to closed and a Transaction object is created. This normally happens within 24 hours; however hotels, airlines, and car rental companies are able to capture up to 30 days after authorization.
I know it's a bit confusing because you feel like you captured the transaction already, but in a way it's abstracted away from you behind the scenes.
durrell-issuing-settlement
idle glacier
ok. so we will just wait then and we should eventually get the issuing_transaction.created event within 24 hours.
correct?
broken spear
I don't know about the exact delay. But yes you will at some point get the Transaction and its corresponding Event
idle glacier
Ok. Thank you for clarifying this.
broken spear
sure thing!
idle glacier
Interestingly the Issuing available balance decreased the amount of the charge. I assume that is because the amount of the charge is being held since we have a BalanceTransaction of type issuing_authorization_hold. Despite the Issuing balance decreasing we did not receive the balance.available event. I guess that event will occur when the balance transaction of type issuing_authorization_release is created?
broken spear
yes
we hold the funds with an Authorization. And separately we clear the Authorization (reverse it) when we take the funds for real with a Transaction
in a way it's what you see on your own bank app as a consumer. You'll see those "pending transactions" like after paying at a restaurant (which is the hold before tip) and they clear/settle a few days later sometimes
idle glacier
ok. Thank you.