#Edi-card-vs-pms
1 messages · Page 1 of 1 (latest)
Hi there! PaymentMethods are the higher-level object that can be of various types like card or ach_debit. The Card object gives you the specific details of the card. They basically work together if that makes sense.
Feel free to ask more specific questions if that doesn't make sense.
Yup, no probs, I was waiting for you to create the thread first
So in itself, "cards" is more like a lower level feature, compared to payment methods
which offer the same functionality, while being more flexible
The only difference that meets the eye in-api, would be that I would have to send Stripe the card details, instead picking them up via your cardfield, right?
Nope, you create PaymentMethods via Elements, which will contain a card object that has the card-specific details.
Which flow are you looking at using?
Are you following certain docs?
Currently, in production I've already successfully implemented the payment methods
But just noticed the "Cards" section in Stripe's API reference
So I was wondering, if it wouldn't be easier for the future, to just use cards, instead of paymentmethods
Our apps are made with react-native, so it's using stripe-react-native lib
No, Cards themselves are really more legacy... you used to just create Cards. Now PaymentMethods are built on top of Cards.
Ok, then two more questions arise. Hows does one create an actual card? Is it also via your "elements" ? Or do i pick the details myself and send them via API to you (as per stripe's api reference)
The second question would be, is there any "end of life" announced for the cards endpoint?
Honestly you are going down rabbit hole that you should mostly ignore.
No Cards won't be deprecated.
You should just focus on using PaymentMethods and then look at the Card hash for the details you need about the Card
But you shouldn't worry about creating Card objects.