#brandan_best-practices

1 messages · Page 1 of 1 (latest)

mortal pecanBOT
#

👋 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/1460719800769843406

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

stiff zenith
#

Hi there,
when you are saying, that your are updating users credit cards, what exactly do you mean?

mortal pecanBOT
marsh kelp
#

The user is on a update credit card page within our mobile app (which uses NET MAUI), so we do not use the Stripe SDK - everything comes through and is handled server side in our system.

So the customer already exists in Stripe, they have a payment method/card already attached.

We are swapping to use the setup intents API, and just trying to figure out how to pass along the card information with the set up intent creation

haughty mesa
#

Hello
Taking over as my colleague needs to step away soon

#

The legacy card objects you've created are compatible with the newer APIs like PaymentIntent, SetupIntent and PaymentMethods APIs.

So you don't really need to "migrate" them as such - https://docs.stripe.com/payments/payment-methods/transitioning#compatibility

If you still do want to have the customer re-confirm their payment methods then you can pass the existing card_xxxx token as payment_method parameter and confirm the SetupIntent - https://docs.stripe.com/api/setup_intents/create#create_setup_intent-payment_method

If 3DS is required then SetupIntent will move to requires_action status. Since you're doing everything server-side, you'd need to make sure 3DS is handled manually. See: https://docs.stripe.com/payments/3d-secure/authentication-flow?platform=web#when-to-use-3d-secure

marsh kelp
#

We will have 3DS handled manually.

My question is not if we need to migrated the cards.

My question is - When we use the setup intents api can we pass along the card details with that, rather than having to generate the payment method with card details separately and then attach it to the setup intent

#

Can we do it all with the 1 setup intents create API call

haughty mesa
#

When you say card details, what exactly do you mean? do you mean raw card data like number, expiry etc OR do you mean existing card_xxx token?

marsh kelp
#

I mean raw card data

haughty mesa
#

Gotcha. Hmm I'm not sure SetupIntents API supports that but can you try passing raw card data to payment_method_data.card when you create the SetupIntent?

Edit: you'd also need to pass the type

#

something like

  { 
    payment_method_data: {
      type: 'card',
      card: {
          number: xxx,
          exp_year: xxx,
          exp_month: xxx,
          cvc: xxx,
      }
    }
  }
#

Okay just tested it myself and it works

#

So yeah, you can do the above

marsh kelp
#

okay, I am trying to set that up using c# with the NET api

#

I'm having trouble figuring out exactly what that object is to create with the payment method data

#

would that be

var options = new SetupIntentCreateOptions
{
    Customer = customerId,
    Usage = "off_session",
    PaymentMethodData = new PaymentMethod <--- this is what I am not able to figure out what this object should be in order to add the type and card details
    {

        Type = PaymentMethodType.CreditCard,
        Card = new Card
        {

        }
    }
};
haughty mesa
marsh kelp
#

Those are for setup intent confirms

#

oops, maybe that link changed or I misread it. Let me see if this works

haughty mesa
#

Sorry, I edited it

marsh kelp
#

SetupIntentPaymentMethodDataOptions <-- this object does not contain anything to assign a type or card to

#

the other option is SetupIntentPaymentMethodOptionsCard but that object also has no way to pass in card details either

haughty mesa
#

Hang on, let me check

marsh kelp
#

Thanks, appreciate it 🙂

haughty mesa
#

Can you try

 var options = new SetupIntentCreateOptions
            {
                Customer = customerId,
                Confirm = true
            };
            options.AddExtraParam("payment_method_data[type]", "card");
            options.AddExtraParam("payment_method_data[card][number]", "4242424242424242");
            options.AddExtraParam("payment_method_data[card][exp_month]", 12);
            options.AddExtraParam("payment_method_data[card][exp_year]", 2029);
            options.AddExtraParam("payment_method_data[card][cvc]", 123);

            var service = new SetupIntentService();
            SetupIntent setupIntent = service.Create(options);
            Console.WriteLine(setupIntent);
#

Ah yeah, that works

#

just tested it locally myself

marsh kelp
#

That is looking better, no more warnings or errors in my IDE

haughty mesa
marsh kelp
#

I haven't fully wired it up to my controller yet, but can run with this and see if this works for me. If you are getting success locally that's great!

Couple other questions that I'm pretty sure I've confirmed via docs, but while I have you if you can confirm these assumptions:

  1. If a card were to be declined during the setup intent, the users payment method would not update and their existing(old) card would stay present?
  2. If a card were to require 3DS and it were to never be completed/or they failed 3DS then the card would not be added to the account and their old card would remain?
marsh kelp
haughty mesa
#

1/ Creation of a new payment method doesn't affect the old cards. They should stay intact until you detach/delete them

2/ Yes, an incomplete SetupIntent does not impact existing payment methods.

#

So are these considered beta features/parameters? Or just not public? Curious what that means for LTS when using these, any risks with doing it this way?
More so private features than a beta. Passing raw PAN to Stripe APIs is prohibited unless you have your own PCI compliance etc. So to avoid confusion, these parameters aren't publicly documented or made available

#

There shouldn't be any long term risk or deprecation (unless something changes drastically)

#

even so there'll be comms in advance to make sure we don't break your integration

marsh kelp
#

okay, long term on our end we plan to do a rewrite and use native stripe iOS/Android SDKs which would handle a lot of this stuff better. Just trying to modernize a bit and work with what we've got

#

how do those comms go out? Not sure the best way to make sure we are in the loop

haughty mesa
#

Stripe has ways to identify traffic pattern and associate them with merchant account IDs. So we'll send an email to the email address on your Stripe account.

marsh kelp
#

I'm pretty positive our team has our own PCI compliance, if we pass things along this way as we are discussing with these parameters would there be concern of something happening, or would Stripe reach out and send us comms if there was any PCI issue so it could be corrected? This stuff is a little new to me with the PCI but I know members of our team work on that

haughty mesa
#

Sorry for the confusion, what I meant was that Stripe will potentially reach out in case we change how things work with undocumented parameters that you'll be using.

For any PCI issues, you'd need to work with your team since you have your own certification.

marsh kelp
#

Gotcha ok, that makes sense. I will confirm with my team on that stuff. It sounds like there are other ways to do what we need to do but it would require setting up the cards separately using the old way of doing things with the tokens and stuff right?

With the ideal case being we go the route we discussed passing it all along with the create method and those private parameters

haughty mesa
#

It sounds like there are other ways to do what we need to do but it would require setting up the cards separately using the old way of doing things with the tokens and stuff right?
I mean single API call is def better rather than creating a separate token unless you plan to do anything else with the token.

#

I was just unsure if you wanted to re-confirm the existing payment methods (but now with 3DS) or wanted to create new payment methods

#

I originally thought the former hence I suggested that first 🙂 otherwise, for new payment methods - single API call is the way to go

marsh kelp
#

We have it set up in our system so that 3DS cards will end up getting re confirmed in a flow where they complete 3DS, so we should be fine there, our users will go through and make those updates when they are on session.

I just confirmed that we do have PCI compliance so shouldn't be an issue going the route of the single api call!

#

I will continue work on this and see if I can get this working with some postman calls as I am standing things up - really appreciate the discussion and help with those private parameters!

haughty mesa
#

Great!

#

NP! 🙂 Happy to help

marsh kelp
#

Is there a place where I can see all the private parameters for card details? If I needed to pass the name of the card for instance, how can I find what that private parameter looks like

haughty mesa