bwurtz999-terminal

[unborn thicket]

hey again

[normal mason]

hello!

[unborn thicket]

is this on the terminal device or in your POS?

[normal mason]

terminal device

[unborn thicket]

which model, and are you able to share a reader ID?

[normal mason]

the p400

tmr_EVAzwbVaBmlb4X

this is a dev terminal I test with

but it happens with all of my production readers as well

[unborn thicket]

and can you share an example payment intent where this happened?

thanks for those 🙂

[normal mason]

pi_3JfOuCCXMuDrMdnf04DfrY8X

^dev

just now

the context here is that the backend of my application appears to be mixing up payment intent id's between requests. That's not a Stripe issue and I'm working on that separately. But, I feel like it should not produce a success message before the charge is captured

right?

steps to reproduce

1. create a payment intent

2. add some amount to the payment intent

3. call terminal.collectPaymentMethod in JS

4. Attempt to capture the wrong payment intent on the backend (my issue - not Stripe's)

5. the terminal reader displays a success message

oh I'm seeing now in the logs that the charge associated with this payment intent (ch_3JfOuCCXMuDrMdnf0xa4ej0H) is marked as succeeded

outcome.seller_message = 'Payment complete.' but I literally hardcoded in the wrong payment intent ID when I ran this

try
        {
            $payment = $stripe->paymentIntents->capture(
                // this is the wrong ID
                'pi_3JfOtPCXMuDrMdnf0pYsBGIZ',
                [
                    'transfer_data' =>
                    [
                        'amount' => $pi->amount - ( $stripe_fee * 100 ),
                    ]
                ]
            );
        }
        catch(\Stripe\Exception\InvalidRequestException $e)
        {
            \Log::error($e,
                [
                    'use_case_id' => $this->useCaseId,
                    'organization_id' => $this->organization->id,
                    'organization' => $this->organization->name,
                    'user_type' => $this->user_type,
                    'user_id' => $this->user_id,
                    'invalid_payment_intent' => $pi->id,
                    'payment_intent_id_check' => $this->user->payment_intent_id,
                ]
            );

            $this->paymentError = true;
            return true;
        }

[unborn thicket]

So, the terminal is showing that because the payment is confirmed with the customer card, though it does still require capture by you

but from a customer perspective they're done, and likely the authorization is exposed to them and appears charged even if you have yet to capture

perhaps you've got your capture ID's out of sync and you capture the previous test payment?

[normal mason]

so the success message before capture is the expected behavior?

[normal mason]

yes - I did this on purpose to simulate what is happening in production (again - I am working on fixing this and I do not believe it is related to Stripe)

[unborn thicket]

yes, it successfully collected the payment method from the customer and you associated it with the payment

[normal mason]

but then on this error they are not actually being charged, right?

I'm confused because in the logs the charge reads as successful but the payment intent remains uncaptured. Which one determines if there is actually a charge to the customer?

[normal mason]

this is accomplished with the client secret I pass to the front end, correct?

[unborn thicket]

they have been charged, you did the auth with deferred capture. This hits their card and holds the funds.

you need to capture them, or cancel, or that will eventually expire and be refunded to them

[normal mason]

ok thank you

this discord is always very helpful. thanks again

[unborn thicket]

you're quite welcome, happy we can help 🙂