#Ender1776 [syndicate]

1 messages · Page 1 of 1 (latest)

echo sparrowBOT
lament scaffold
#

Hi there

velvet halo
#

hello

lament scaffold
#

Hmm let me take a look at best way to handle this

velvet halo
#

the goal, just FYI is that we don't have to ask the user for anything outside the platform payment screen, we already know what subscription item they picked

lament scaffold
#

Yep makes sense. And to clarify you are seeting requiredShippingAddressFields right?

velvet halo
#

yes, and billing, and that works for apple, just not google, but how to do this with subscriptions, without creating one ahead of time?

lament scaffold
#

Well with Subscriptions you want to create the PaymentMethod ahead of time using createPlatformPayPaymentMethod

velvet halo
#

by works, I mean it will return the values, (NOT for confirmSetupPlatform... though for some reason)

lament scaffold
#

Then you can create the Subscription and set the PaymentMethod as the default

velvet halo
#

yeah, but that means it requires confirmSetupPlatformPay right?

lament scaffold
#

So that you don't hit the auto tax error for not having an address

#

No it is a completely separate method from confirmSetupPlatformPay

#

For Google Pay you want to set shippingAddressConfig.isRequired

velvet halo
#

for google pay I am, but its not returning it, in a strange thing, it looks like the stripe RN devs added the settings, but the stripe library SDK folks have not integrated it

#

going to try confirmsetupplatformpay, back in a sec

#

sorry, mean createplatformpaymenthod

lament scaffold
#

Give it a try

#

I actually haven't tested this full flow myself

#

But will work on spinning it up on my end as well

velvet halo
#

ok, so that also doesn't return shipping address

#

even though its being collected

#

not sure why they didn't just go with a common interface for the payment responses

lament scaffold
#

Hrrmmm that actually does make sense since there isn't a shipping_address param on a PaymentMethod object.

#

You explicitly want to collect a shipping address for this correct? And not use billing address I assume

velvet halo
#

yeah, but it accepts shipping in config, and asks for shipping in payment

#

yeah, and it does all that, its just not returning it properly

#

so, so far, only confirmpp is returning all the requested and collected details, but that doesn't works with subs and stripe tax

lament scaffold
#

Yeah this may not be well-supported yet on the React Native SDK unfortunately. Let me double check with a colleague. Give me a moment.

velvet halo
#

appreciate it

lament scaffold
#

Wait so when you used createPlatformPayPaymentMethod or PPConfirmSetup you didn't see billing details attached to the PaymentMethod?

#

Do you have an example PaymentMethod ID I can look at?

velvet halo
#

lol, so its different for EVERY one. confirmSetupPP doensn't return ANY collected info, createPPPM only returns Billing, confirmPP returns everything

lament scaffold
#

Huh that's very strange. Do you mind providing me a PaymentMethod ID that was tokenized using the 3 different methods? Would help to be able to file a comprehensive ticket as well to get this flow improved (regardless of the best workaround we find)

velvet halo
#

sure

#

Here are the setup params:
applePay: {
cartItems: [
{
label: 'Subscription',
amount: subscriptionData.total, // subResponse.totalPrice,
paymentType: PlatformPay.PaymentType.Immediate,
}
],
merchantCountryCode: 'US',
currencyCode: 'USD',
requiredShippingAddressFields: [
PlatformPay.ContactField.PostalAddress,
PlatformPay.ContactField.Name,
PlatformPay.ContactField.EmailAddress
],
requiredBillingContactFields: [
PlatformPay.ContactField.PostalAddress,
PlatformPay.ContactField.Name
]
}

#

this is for the confirmSetupPP (no user info returned at all):
{
"created": "1682361345000",
"paymentMethodTypes": [
"Card"
],
"paymentMethodId": "pm_1N0UEtEw8dry0on1jjXMbyO8",
"paymentMethod": null,
"livemode": false,
"clientSecret": "seti_1N0UEnEw8dry0on1bfARb12Q_secret_Nm2J022j0QECMmfaNqAvazULPkAHKx4",
"usage": "OffSession",
"lastSetupError": null,
"description": null,
"status": "Succeeded",
"nextAction": null,
"id": "seti_1N0UEnEw8dry0on1bfARb12Q"
}

#

this is for the createPPPM (only billing info returned):
{
"Card": {
"funding": "credit",
"preferredNetwork": null,
"expMonth": 12,
"availableNetworks": [
"visa"
],
"country": "US",
"last4": "4242",
"fingerprint": null,
"expYear": 2024,
"brand": "Visa"
},
"Ideal": {
"bankName": "",
"bankIdentifierCode": ""
},
"Upi": {
"vpa": null
},
"Fpx": {
"bank": ""
},
"paymentMethodType": "Card",
"billingDetails": {
"email": "marr.adam@gmail.com",
"name": "Adam Marr",
"phone": null,
"address": {
"line2": null,
"postalCode": "23112",
"state": "VA",
"line1": "9613 Haveridge Ct",
"country": "US",
"city": "Midlothian"
}
},
"Sofort": {
"country": null
},
"BacsDebit": {
"fingerprint": null,
"last4": null,
"sortCode": null
},
"customerId": null,
"AuBecsDebit": {
"fingerprint": null,
"last4": null,
"bsbNumber": null
},
"SepaDebit": {
"bankCode": null,
"last4": null,
"country": null,
"fingerprint": null
},
"id": "pm_1N0UiKEw8dry0on1ZTDuv5JR",
"livemode": false,
"USBankAccount": {
"accountHolderType": "Unknown",
"last4": null,
"bankName": null,
"routingNumber": null,
"preferredNetworks": null,
"fingerprint": null,
"accountType": "Unknown",
"linkedAccount": null,
"supportedNetworks": null
}
}

#

I don't have one handy for the normal confirmPP, but it returns all the expected info

lament scaffold
#

Can you run a test and pass a Customer ID to the SetupIntent creation?

#

When you use confirmSetup it returns a SetupIntent with a PaymentMethod

#

Then you would need to pass that to your server to retrieve the billing details

#

it won't be in the response itself

velvet halo
#

ok, wondered that. strange still though, all 3 ask for the same data, the response should be consistent, imo at least

lament scaffold
#

So if you have a sec to test that it would be great (I just don't have a sample spun up right now to test myself)

velvet halo
#

will do

lament scaffold
#

👍

velvet halo
#

yeah, checked the code, we already pass customer when creating the setupIntent, tried it again, and same thing, no shipping data returned in the response (as we are aware of), but also the customer information is not updated either: cus_Nlzr3qichCpqMb

lament scaffold
#

Hmm the example you provided above didn't pass Customer to the SetupIntent

#

All you do is pass pmt: card

velvet halo
#

what do you need to check the one I just ran?

lament scaffold
#

I'm looking at that Customer and don't see a SetupIntent associated

velvet halo
#

yeah, ok, i see the logs for that last one too, one sec

#

ok, resolved the customer not being passed to the setup intent

#

but same thing, it does attach the payment, but isn't updating the customer data, and I don't see shipping being stored or returned anywhere

lament scaffold
#

Hmmm

#

Can you try retrieving the Customer server-side

#

I think I do see the Shipping set there

#

But you wouldn't see it on your client-side response

velvet halo
#

i can look, its not showing in the dashboard though, like our normal card customers

lament scaffold
#

Yeah I agree which is weird

#

But internally I do see shipping set for the Customer

velvet halo
#

this is from the stripe api:
{"id":"cus_Nlzr3qichCpqMb","object":"customer","address":null,"balance":0,"created":1682352243,"currency":null,"default_source":null,"delinquent":false,"description":null,"discount":null,"email":null,"invoice_prefix":"6ADAFDD4","invoice_settings":{"custom_fields":null,"default_payment_method":null,"footer":null,"rendering_options":null},"livemode":false,"metadata":{"userId":"a4fe0112-f59c-4547-8131-8862281b81b7"},"name":null,"next_invoice_sequence":1,"phone":null,"preferred_locales":[],"shipping":{"address":{"city":null,"country":null,"line1":null,"line2":null,"postal_code":"23112","state":"VA"},"name":"Test Test","phone":null},"tax_exempt":"none","test_clock":null}

lament scaffold
#

Yeah okay so shipping is there

velvet halo
#

it has the shipping state and zip, which I had put there to try and hack the tax

lament scaffold
#

Oh

#

That was already there?

velvet halo
#

but thats not from the platform pay, which would include line1, city

#

yeah

lament scaffold
#

Oh oh oh

#

I see

#

I see your Customer creation now

#

I thought that was from your PlatformPay submission

#

Okay this feels like a gap/bug in PlatformPay

velvet halo
#

was hoping that would be enough to solve the TAX problem

#

but it wasn't

lament scaffold
#

Hmm no? That should be enough to calculate iirc

velvet halo
#

yeah, but looking into it more, it looks like it can calc all the way to "rooftop" level detail for tax, so guessing it wants the full address

#

yeah, if you cut a ticket, a few things I'd suggest, and that is just having a common interface for the user details (the responses can extend it to get more detailed), but both apple and google pay should be returning email, name, billing and shipping for all responses that use the platform payment (create, pm, setup etc)

lament scaffold
velvet halo
#

ahh, maybe country is the missing link

lament scaffold
#

Oh yeah whoops

#

You are setting State

#

I misread and thought that was Country

velvet halo
#

yeah, state and zip are all we have (currently US only)

#

will set country, see what happens

lament scaffold
#

Yep that should do it. I'll still cut a ticket to improve this PlatformPay flow

#

But really if you have postal + country up front then you don't need shipping at all via PlatformPay if you are just using that for tax purposes

velvet halo
#

we are actually shipping physical products

lament scaffold
#

Ah okay in that case yeah this will be an issue

velvet halo
#

another sort of shortcoming of the stripe sub model, which assumes everything is an ongoing service

lament scaffold
#

I think it is more a shortcoming of the React Native SDK right now tbh

#

You can handle all of this just fine via Web

#

But the RN SDK is still catching up

velvet halo
#

well, i mean for things like updating the subscription. For instance there is no way to update the product or quantity without billing immediately. Which makes sense if you are providing a ongoing service of some kind, but if my users want to just switch from 4 items a month to 6 items, or switch from monthly to quartlery there is no way to do that in the existing model without canceling the sub and creating a new one, if I don't want to change the billing date. Maybe with schedules, but that was getting way to complex for our use case

lament scaffold
#

There are definitely ways to handle this it just does get complicated. You can do things like use trial periods to move the billing cycle anchor. There is no doubt that it isn't straightforward to handle a use-case like that but the reality is that we try to build for many many different use-cases which does lead to this complexity as well. Overall I hear you though -- there are definitely a lot of areas we have for improvement in terms of streamlining some of these flows.

#

I'm going to file a report to improve the PlatformPay + Subs + Auto Tax flow for React Native.

velvet halo
#

yeah, trial periods is how we solved it (with yall's help) but we still had to cancel and create a new one for it to work, all good tho, one step forward at a time

lament scaffold
#

Happy to file other feedback as well if you want to talk through anything futher

velvet halo
#

thanks, working on trying to country fix for tax, but thats it as far as feedback for now

lament scaffold
#

Sounds good. Pop back in if we can help any further.

velvet halo
#

OK, so that worked, but hopefully they'll have some additional solutions ahead, because the problem is it doesn't allow us to update the amount if needed on the immediate sale for tax. Like, I can put in a state without sales tax for my profile info, but then choose a state with 10% sales tax in the shipping section of apple pay. Because the only 1-screen-express-pay solution right now appears to be confirmPP, users could, in theory, "game" the system for lower cost on the first purchase. It also doesn't update the customer data or use the shipping or billing details in the subscription or invoice, or update the customer, but I expected that, will just have to update the customer data after, and hopefully future sub/invoices will reflect that data and the updates tax rate?

lament scaffold
#

Yep that is all correct.

#

Hopefully most won't change state often if you are requiring postal...

#

But yeah updating based on the address submitted for the PaymentIntent is the best workaround right now

velvet halo
#

and that should update the future invoice price, based on the new tax location, if I update the address and shipping address on the customer?

lament scaffold
#

And it assesses each time an Invoice is finalized.

velvet halo
#

great, thanks for your help today