#Medwe-paymentsheet

1 messages Β· Page 1 of 1 (latest)

sour cedar
#

@old swift it probably means something is wrong with the ephemeral key for the customer your backend is returning

old swift
#

Ok i see, can we somehow include our backend developer in this thread, as I don't know the the details of that part of the implementation

sour cedar
#

well you can also debug it on the frontend a bit

#

not sure what your code looks like but you want to look into this part

#

i.e do you get a key from the backend at all, if you do, what does it look like(it should be a JSON string I think(double-checking that)) etc

old swift
#

Yes i receive an ephemeral key, it looks like this: "ephkey_1K02wJKOIcfDnxOZQGLdBrtF"

sour cedar
#

ok one sec, I need to check something(but I think that's the wrong value)

#

ok yeah, the value your backend should give you is the actual secret ek_test_xxxxx basically

#

what it's actually sending you is the id field of the object, but it should send you the .secret field

#

hopefully your backend developer can fix that!

old swift
#

He is currently having a break but I will tell him right away. In case everything works fine now, thank you very much for your quick help and have a great day πŸ™‚

If there's another issue here, should I reply in this thread?

sour cedar
#

if it's within the next hour or so, sure!

old swift
dark mulch
#

Hmm that doesn't sound right, it's used in the examples in the SDK repository, eg:

#

Are you encountering an error when you try to use it?

old swift
#

No it simply doesn't exist it seems. Even when i look into the the PaymentSheet.Configuration class itself, it definetely doesn't have a member called allowsDelayedPaymentMethods. Though the link you sent is about the SwiftUI Class, not the Swift class, I agree that this absolutely should be here.

#

Oh, maybe i actually do have an older version of the SDK. Let me quickly try to update the pod

#

Ok, so the version i used was 21.8.1, i just updated to new newest version 21.9.0 - and there it is

#

I'm very sorry, that was a really dumb mistake on my side

dark mulch
#

not a problem! glad you got it figured out πŸ™‚

old swift
#

So actually I now have another issue, maybe you can help me with that. I have now set said property to true, have enabled the paymentMethods SOFORT and SEPA Direct Debit in the Stripe Dashboard and our server listens to all necessary webhooks. The issue is that the payment sheet still doesn't offer any methods besides apple pay and card payment.

Is there any other component we might be missing? Or does enabling a payment method maybe take some time to take effect?

sour cedar
#

it's probably worth looking at payment_method_types on the PaymentIntent (https://stripe.com/docs/api/payment_intents/object#payment_intent_object-payment_method_types) if you're using automatic_payment_types:{enabled:true} (or just post the pi_xxx here and I'll look β€” not every method is available on every type of intent (like depending on if you use setup_future_usage a lot of things are not possible sine some methods are one-time only) so maybe they get filtered out). AFAIK there's no delay in taking effect at least

old swift
#

Our backend developer just sent me this snippet of his implementation

#

I suspect the putExtraParams shouldn't be used here. I'll ask him to update the SDK, if it doesn't work anyway I will message you again. Thanks for your support!

sour cedar
#

it should be ok to pass, if your account supports SEPA and Sofort and they're active in your dashboard they should be returned as payment_method_types on the PaymentIntent and the iOS SDK should show them(the idea of the automatic types is that we present every possible option compatible with the payment you're attempting). but yeah, if you have the pi_xxxx I could take a look which might clear things up since this can get complicated

old swift
#

Alright, I'll quickly test if the update on the SDK changed anything and send you the ID right after! πŸ™‚

lusty gull
#

pi_3K068IKOIcfDnxOZ0m0SO2Zc

old swift
#

The outcome is still the same, would be great if you could look into it for us πŸ™‚

sour cedar
#

looking

#

ok cool.

  • for SOFORT, it's because you are passing setup_future_usage:on_session . SOFORT is a one-time use payment method(you can't save the details and charge them again), so it's not compatible and won't be returned.
  • for SEPA DD, that is being returned from the backend API at least. You're saying that when using that PaymentIntent with the PaymentSheet in iOS though it doesn't present it as an option? That one I'll have to take a bit of time to replicate on my account to work through something so give me a bit.
sour cedar
#

sorry, this should be faster, but I'm having a really hard time getting my XCode<->Github connection to work properly to let me install the latest Swift package for stripe-ios, ugh.

old swift
#

Not a problem, we very much appreciate your effort!

sour cedar
#

ok apparently my set up is completely broken and I can't install our SDK into my app any more, so I can't test this.

#

so what I'd suggest double-checking on your end is you are definitely using the 21.9.0 version of the library, and that you definitely passed allowsDelayedPaymentMethods .

#

AFAIK that PaymentIntent you shared should just work and show SEPA DD in the app if you've done those things. Might also help to share the exact code of the relevant of your ViewController that uses the confirmPayment function.

old swift
#

Ok, let's take this step by step:

  1. So if I understand this correctly, there's no way to tell the PaymentSheet that it should save card information for future usage, but also offer the user the option to pay using SOFORT or DD?

  2. I just checked, and on iOS we definitely use version 21.9.0 since i just updated the pod earlier today. And as you can see in the code snippet, i also set the allowsDelayedPaymentMethods flag to true

  3. For reference i attached the code where the PaymentSheet is initialized and presented on iOS, maybe you can find an error there

sour cedar
#

1/ for SOFORT, no. For SEPA yes, since that can be saved. So you should be getting the cards and SEPA option. If you changed the backend to not pass setup_future_usage you should get all 3 in the app
2/ makes sense!
3/ seems correct to me, I don't see anything immediately wrong there

#

my guess is there's 'something' that prevents SEPA being shown as an option that is specific to the iOS SDK

#

and I wish I could debug it but my entire set up is broken and I can not make it work, which is frustrating me as I could probably figure this out for you in 10 minutes if I could test your scenario myself

#

ultimately I'd suggest writing to https://support.stripe.com/email and we can look into things(feel free to write in your email you were talking to me on Discord by name)! (unfortunately it's the weekend and a holiday in the US so there's not really anyone else we could work with ).

old swift
#
  1. Alright I understand, then how exactly would we go about offering both SOFORT and Card + DD to our customers? Can we let our users make a decision beforehand and set up the paymentIntent differently for each option? So for SOFORT for example, we wouldn't use the PaymentSheet at all or configure it differently?

I understand your frustration, I will contact the support and let them know about the issue πŸ‘

sour cedar
#

Can we let our users make a decision beforehand and set up the paymentIntent differently for each option?
yep, basically it's best to decide that in the flow before presenting the PaymentSheet

#

So for SOFORT for example, we wouldn't use the PaymentSheet at all or configure it differently?
yep you can still use SOFORT but you need a PaymentIntent without setup_future_usage

old swift
#

Alright, thank you so much for your help today! I will now drop your support a mail an take it from there πŸ™‚

sour cedar
#

ok so for what it's worth @old swift I got my environment set up and it seemed to work this way:

#

backend code is

let customer = await stripe.customers.create({
Β Β Β  email: "test@example.com",
});

let pi = await stripe.paymentIntents.create(
{
  amount: "1800",
  automatic_payment_methods: {
    enabled: "true"
  },
  currency: "eur",
  customer: customer.id
});


let key = await stripe.ephemeralKeys.create({
    customer:customer.id
}, {apiVersion:"2020-08-27"} )

console.log(customer.id)
console.log(pi.payment_method_types)
console.log(pi.client_secret)
console.log(key.secret)

and the app code is

// MARK: Create a PaymentSheet instance
        var configuration = PaymentSheet.Configuration()
        configuration.merchantDisplayName = "Example, Inc."
        configuration.returnURL="com.karllekko-ios://sheet-redirect"
        configuration.applePay = .init(
        merchantId: "merchant.com.stripe.karllekko.ios",
        merchantCountryCode: "IE"
        )
        configuration.allowsDelayedPaymentMethods = true

        configuration.customer = .init(id: "cus_xxx", ephemeralKeySecret: "ek_test_xxx")
        self.paymentSheet = PaymentSheet(paymentIntentClientSecret: "pi_xxx_secret_yyy", configuration: configuration)
#

one thing I found from doing this is you definitely need to set configuration.returnURL, if you don't the non-card options won't show up

old swift
#

Is the paymentIntent set up to save payment data? Because in our case it is, maybe that actually causes the SEPA DD to not show up?

sour cedar
#

it is not setup to save the data. If it is(passing setup_future_usage:"on_session", then you only get card it seems. Maybe let me try off_session ...

#

yeah that is just cards too. Hmm.

#

it confused me because you can technically save and charge SEPA DD for future payments, but my guess is we don't support it in the PaymentSheet just yet(since there's complexity in showing a debit mandate text), but now it make sense to me.

#

so yeah I think overall we're just back to , if you want to use those other payment methods, you need to not use setup_future_usage to save that method, so you might ask for if the customer wants to save or not in your UI before showing the payment form, then create the PaymentIntent on the backend appropriately

old swift
#

I see, so the SEPA DD is actually a one-off payment for now? Well at least in the context of the payment sheet that is. Thanks so much for your investigation! You donβ€˜t happen to know whether or not it is planned to add the SEPA DD to the list of saveable payment options in the future, do you? πŸ€”

sour cedar
#

as far as I know ,it is planned (for example it works in desktop Checkout, and we intend the PaymentSheet to be the native mobile equivalent of that), but yeah, it's probably not immediately available because of the mandate requirements, I expect it will be added in future. And yep, for now , from the perspective of the iOS SDK, it's a one-off payment type only.

old swift
#

Alright thanks so much for the help, i appreciate it πŸ‘

sour cedar
#

πŸ‘