#themacproguy_api

1 messages · Page 1 of 1 (latest)

civic kindleBOT
#

đź‘‹ Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

đź”— This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1230901837792673923

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

knotty carbonBOT
rugged sable
#

If that is the only way to send an email, it sounds like I'd have to make two API calls, one to set receipt_email to null, another to set it back to the same email.

blazing rampart
#

Thanks for the info, looking in to what the dashboard does here

#

I hope it is not "the exact same thing but the dashboard just works differently"

rugged sable
#

Lol, I know the dashboard normally posts things to the request logs but I didn't see anything related in workbench when doing it via the dashboard

blazing rampart
#

It looks like the dashboard has its own resend_receipt endpoint

rugged sable
#

Is that by chance something hidden that I would be able to hit or is that dashboard only?

#

I feel like that should be available in the API. I don't necessarily like updating a payment intent after its confirmed. Hitting an action on that endpoint like /v1/payment_intents/pi_3P2GYVJJlPLJUaju0RR9QBBF/resend_receipt would be nice. I also noticed if you set a different email when in the dashboard, it actually does not update the receipt_email value on the PI.

blazing rampart
#

Not seeing it in the API ref. Do you have a link to the doc where it mentions that we should send a new receipt when the email is updated? That will be helpful if I have to file something for this

rugged sable
#

Sure, one sec

blazing rampart
#

Yep, agreed that that makes sense as a way to do this. I have a feeling we don't resent the receipt when the email is set to the same thing because it is common to resend fields that are not being changed, so that might result in a lot of extra emails.

rugged sable
#

In reguards to sending all the fields each time, I actually had to sadly add some logic as creation of a payment intent will fail if you have the receipt_email key present but set to null. It accepts the null/empty value on update though. Super super inconsistent.

#

Excerpt from the model creation observer.

            $stripe = app()->make(StripeClient::class);

            $data = [
                'amount'               => $payment->amount,
                'currency'             => 'USD',
                'payment_method_types' => ['card_present'],
                'capture_method'       => 'automatic',
            ];

            if ($payment->email) {
                $data['receipt_email'] = $payment->email;
            }

            $paymentIntent = $stripe->paymentIntents->create($data);
#

The update observer just passes all fields directly into the update call without issue.

blazing rampart
#

Gotcha, thanks for that detail. Unfortunately it looks like updating to null and back would be the best workaround for now. I will file a feature request for exposing the resend_receipt endpoint and will file about the inconsistency with that field accepting null between our create and update endpoints

knotty carbonBOT
rugged sable
#

Awesome, thank you! I know there wont be any ETA or anything on that feature request but can I get keyed into an email to let me know when that is a thing?

#

I am subscribed to the change logs but separate email is always nice 🙂

blazing rampart
#

For this I would say just keep an eye on the changelog