#benk-customer-name
copper shale
@wispy root you can either store that information directly on the Customer, or in the billing_details of the relevant PaymentMethod(s)
benk-customer-name
gusty smeltBOT
wispy root
I see.
When creating deffered payments, is it possible to pass the customer email so that a receipt will be email, but do not display it on the connected account?
hidden flare
👋 stepping in as koopajah needs to step away
wispy root
ok hi
hidden flare
So you can use receipt_email on the PaymentIntent to specify an email address to send the receipt
Then if you don't specify an email for the Customer that won't show up in the Dashboard (but it will in the logs and the email portion).
No way to completely hide this really if you send a receipt email
wispy root
ok. Is there stripe api call to send a receipt to a customer by specifying a PI id and their email?
hidden flare
No that doesn't exist
Like that is what you do with receipt_email when you create the PaymentIntent
But there isn't a separate API for this
wispy root
I see. How about generating a receipt via api?
hidden flare
After the payment has already been created?
hidden flare
Yep then you actually update the receipt_email on the Charge: https://stripe.com/docs/api/charges/update#update_charge-receipt_email
When this is udpated a new receipt will be sent
If you want to resend, you can set it to an empty string and then update it back to the previously set email
wispy root
Ah interesting... what if the email fails to send? will stripe revert back to the previous email?
hidden flare
By "failed to send" do you mean like it bounces from the recipient?
wispy root
yes
hidden flare
And no, it won't revert
hidden flare
No, you can only trigger receipt emails in test mode manually via the Dashboard by clicking the "send receipt" button.
Ah actually if you use the owner email on your account it might work 🤔
I can't quite remember for that. We do send Invoice emails to the owner email on the account.
But don't recall if we do that for Charge receipt emails as well.
So you can try that
wispy root
will try it
So if I generate a paymentIntent with the customer email - the receipt will be sent right away?. I am thinking I can create the PI on the connected account with the customer's email, and after this call completed, create a new call to update the email to something like customer@myapp.com so the connected account doesn't have access to it. Will that work? Will the connected account still be able to see the original email that was attached to the PI?
hidden flare
You are working with Standard Accounts here?
wispy root
yes
hidden flare
Okay really they will always be able to see anything that is set here... why are you trying to avoid this exactly?
wispy root
Trying to avoid sharing our customer's email with the merchants they purchase from on our app
But it looks like we will need to handle sending receipt on our own
hidden flare
Yeah there is a specific spot when you view the Customer in the Dashboard that will indicate these emails that are sent so if this is a concern you will need to handle this outside of Stripe
wispy root
makes sense.
One more question if you don't mind.
When IinitPaymentSheet in the react native lib and pass confirmHandler - is tere a way to resolve it without intentCreationCallback. If not, does intentCreationCallback({ error: { code: 'Failed', message: 'Oops' } }); go to the stripe server and records the event?
hidden flare
Did you look into the customFlow path that was discussed at the end of last week?
If you are trying to hack around the confirmHandler then I think the customFlow is the way to go
hidden flare
Oh then my understanding is that you shouldn't even need to confirmHandler at all?
wispy root
When using confirmHandler, it will generate a PM, which I can then clone on the server and create a PI with it.
If I don't use it, then I need to create a PI and pass it to initPaymentSheet. Yes, I probably could create a PM and PI when presenting the paymentSheet, but if the customer doesn't confirm the payment, these PIs will be listed on the account for no reason
You know what I mean?
It's cleaner to generate the PI when the customer clicks pay
hidden flare
I don't understand why you have to create it before the customer clicks "pay" in this case?
wispy root
initPaymentSheet expects either intentConfiguration with a confirmHandler or a PI
hidden flare
Right so you can give it intentConfiguration and then just never actually handle the intentCreationCallback
Since you are confirming server-side here
After you clone
wispy root
True, but if I want to get the PM that I will soon clone, I need to run confirmHandler
hidden flare
Right but you don't need the clientSecret at all, no?
wispy root
no
hidden flare
No to which part?
wispy root
haha. No I don't need it
so you're saying don't clone, but create a PM on the server?
hidden flare
You create the PM --> clone --> create/confirm the PI server-side --> show your own success/error on frontend based on the result of that server-side PI confirmation
wispy root
To get the original PM, I would need to get it from confirmHandler. Unless I actually don't need it. I can probably just create a PM, a PI and done.
hidden flare
Yep you use confirmHandler for the PM
If you are going to clone
But still no reason to ever have to deal with intentCreationCallback
wispy root
Yes, I know. I already have it working, let me show you what I mean... One sec
hidden flare
Kk
wispy root
I have:
// Create the sheet
const { error: initPaymentSheetError } = await initPaymentSheet({
merchantDisplayName: 'xxx',
customerId: user?.stripe?.customer,
customerEphemeralKeySecret: ephemeralKey,
intentConfiguration: {
mode: {
amount,
currencyCode: 'USD',
},
confirmHandler,
},
customFlow: true,
});
// Display the sheet
const { error: presentPaymentSheetError, paymentOption } = await presentPaymentSheet();
// A button click confirms the paymentSheet, which runs `confirmHandler` which returns the paymentMethod
await confirmPaymentSheetPayment();
// Once I have the PM, I send the id to the server, clone, create the PI and auto confirm
Looks good
wispy root
ok, so now the issue is this....
// A button click confirms the paymentSheet, which runs `confirmHandler` which returns the paymentMethod
await confirmPaymentSheetPayment();
confirmHandler:
const confirmHandler: IntentConfiguration['confirmHandler'] = async (
paymentMethod,
shouldSavePaymentMethod,
intentCreationCallback
) => {
const customerId = paymentMethod.customerId; // If the payment method returned has a customerId, it's already attached to a customer and we don't need to save it
// Finally, let's calculate the amount to pay merchant and DineDen's application fees (10% earnings).
const merchant_payout_amount = breakdown.total_with_tip;
const application_fee_amount = Math.floor(
breakdown.total * DineDenPricing.merchantSaleComission
);
const variables = {
owner_id,
payment_method: paymentMethod.id,
should_create_setup_intent: !customerId,
customer: user?.stripe?.customer,
merchant_payout_amount,
application_fee_amount,
description,
receipt_email: authUser?.emailVerified ? authUser.email : '',
};
await GQL_stripeCreatePayment({
variables,
});
// Below is the issue. Until now, await confirmPaymentSheetPayment(); will not be resolved unless I run something like this:
intentCreationCallback({ error: { code: 'Failed', message: 'Oops' } }); // Throw an error so we can resolve confirmHandler.
};
Why do I need it resolved? because I need to clear the cart and show success after confirmPaymentSheetPayment runs
hidden flare
Okay okay
wispy root
I figure I can either do what I did there, or use react state to trigger the event. Both are not really ideal, but they will work
hidden flare
I guess I figured you wouldn't actually need confirmPaymentSheetPayment() to resolve
But sure
So yeah I think just using a default error is good
I'm not sure if intentCreationCallback expects a specific syntax here or not tbh
hidden flare
Right I mean beyond the error.code/message that you are using
wispy root
I was just curious whether I best resolve it with an error or keep it unresolved and use state
hidden flare
Like if we have validation that it is actually one of our messages (which I assume it does not).
I don't think this will add any noise
wispy root
oh no, it's eith er the clientSecret or an error
wispy root
ok. when you pass clientSecret it does
hidden flare
It does what?
wispy root
goes to stripe and confirms the payment
wispy root
🙂
wispy root
no
If I use the default behavior and indeed create a PI with paymentsheet and pass the clientSecret, that intentCreationCallback call will go to stripe, look for the PI and confirm it, and then come back and do the cute animation and close the sheet
Anyway, it's not important. I was just curious whether the error message calls stripe
hidden flare
In the custom flow it should not afaik
hidden flare
Yeah I think that is the best thing to do really.
wispy root
thanks. I appreciate the patience