My Stripe API in Developer settings is 2021+. It means it uses the newer payment methods API with i.e. Ids of payment methods prefix being pm_. I noticed when I create a card through the Dashboard though, it appears in logs as an 2019 API version call, and the card ID prefix becomes card_.
Is it the expected behaviour? My concern is that the Dashboard calls the 2019 API despite 2021+ being set up in the settings.
Related
I have approx 400 members via Wishlist Member(Wordpress plugin - https://wishlistmember.com/) on my website that I'm trying to seamlessly migrate over to Woocommerce Subscription (Plugin - https://woocommerce.com/products/woocommerce-subscriptions/). The Subscription plans are like for like and both using Stripe payment gateway.
I'm using a CSV file to do the import to woocommerce subscription via this plugin - https://github.com/woocommerce/woocommerce-subscriptions-importer-exporter
My issue is for the "payment_method_post_meta" field I require a "src_" payment method ID though for my wishlist member customers the payment id in stripe is a "pm_" payment id.
This is causing the next scheduled payment to fail. Is there a way to get a "src_" payment id for my customers so there isn't any intervention required on the customers behalf?
I recommend working with WooCommerce support on this. Looks like a few others have encountered issues with this plugin when trying to import card source objects:
https://github.com/woocommerce/woocommerce-subscriptions-importer-exporter/issues/251
https://github.com/woocommerce/woocommerce-subscriptions-importer-exporter/issues/252
For additional context, the IDs for card details saved on Stripe can have one of a few different types of formats: card_, src_, pm_. Stripe's older APIs use card and src, while the latest PaymentMethod API uses pm.
When using Stripe with a third-party plugin, it's ultimately up to plugin developers to add support within their tools for these types.
Although not ideal I was able to resolve this issue using WP ALL IMPORT PRO.
So firstly I imported the subscriptions with this plugin - https://github.com/woocommerce/woocommerce-subscriptions-importer-exporter
Though for the "payment_method_post_meta" field I wouldn't include the "_stripe_source_id".
Then I used "WP ALL IMPORT PRO" to import only the "_stripe_source_id"
I then used the following setup to ensure only the stripe_source_id was updated using the _customer_user custom field as the unique identifier.
I am doing a migration for a customer from one platform to another both of which use a Stripe account.
Both platforms only support card payments.
I have noticed, however, that the customers of the existing platform all have a card attached on the Stripe dashboard, but it is not marked as their default payment source. If I retrieve the customers from the API, both their default_source, invoice_settings. default_payment_method and sources.data attributes are null or empty array respectively.
It doesn't sound likely that I'll be able to charge a customer without a default source. I would like to run some tests on data that looks like the production environment, but no matter how I attach a card to a customer, it automatically gets registered as the customer's default source (if they don't already have another). I have in fact no idea how the previous platform manages to end up in a state where a customer has a card attached on the dashboard, but an empty sources-array.
Do any of you know how I can replicate this behaviour using either the API or the dashboard?
When working with Payment Methods, such as attaching a payment method, you must set the customer invoice_settings.default_payment_method explicitly (API ref). With the older Sources API, the default_source was set automatically.
If you attached one of the test payment methods, you can recreate the behaviour you describe: you'd have an attached payment method but no defaults set.
I'm new to Square and want to implement it in a React Native app with a Node backend.
I see that there is a method to save the customer's card details.
https://github.com/square/square-nodejs-sdk/blob/master/src/api/customersApi.ts#L230
But there is also the payment form?
https://developer.squareup.com/docs/payment-form/how-it-works
Firstly, I cannot see if the payment form is even available in React Native - information seems very scarce.
Secondly, even if I do implement that form, I can't see a way to connect it to the customers API endpoint.
I don't want to use in-app payments (i.e. google or apple pay). I want to be able to save card details like Amazon does, and use them whenever a user places an order in app (probably triggered by a node process). I'm not sure if I'm going about this the correct way, guidance would be appreciated.
In-App Payments SDK will be the way to go (and there is a React Native plugin already). The In-App Payments SDK is basically a mobile Square Payment Form, that you linked to. It will generate a secure nonce, and you can use the nonce to save the card on file. The next time the customer comes, instead of bringing up In-App Payments, you can simply call CreatePayment in your backend, with the customer_id and the customer_card_id as the source.
As for "connecting it to the Customers API" - you don't connect it directly per se. You would collect information from the customer, on your own, and pass it directly to the Customers API to create a customer. You can then call CreateCustomerCard using the nonce (generated by In-App Payments), and the customer_id that you just created, to save the card to this customer profile.
I see paypal is upgrading their APIs. I want to collect recurring payments and provide a feature to upgrade / downgrade the plans.
In the samples, paypal is using billing agreements and when I see the docs, it says the API is deprecated please use subscriptions API. I am confused which one to use.
Please help me in this.
PS: Also my product includes one time payments
The PayPal Subscriptions API uses billing agreements and plans, and there are multiple versions. Everything linked from https://developer.paypal.com/docs/subscriptions/integrate/ will be the most recent version.
For one-time (non-subscription) payments, the most robust integration is to have two routes on your server that implement v2/checkout/orders API calls to "create order" and "capture order", combined with this front end: https://developer.paypal.com/demo/checkout/#/pattern/server
For a subscription integration to be similarly robust (in that your server gets an immediate API response of profile activation), you can have those buttons call your server as well: PayPal Smart Subscribe server side
I saw that Google released a new Google Pay API for the web. However, there is also a Payment Request API fo the web. Is Google Pay just a rebrand of Payment Request API? In what cases would you use one API over the other?
The "Payment Request API" is a W3C standard and a part of "Web Payments" effort. This means the API is expected to be implemented by multiple browsers and it's already landed in Chrome, Edge and Samsung Browser. And it's also expected to be available on Firefox, Safari and so on. Payment Request API is never a Google's property and it's an open standard.
https://www.w3.org/Payments/WG/
The Payment Request API is said to allow users to pick their saved credit card information with just one tap. But it's just a part of larger ecosystem. It can integrate with any third party payment apps and allow users to make payment through those apps via the Payment Request API.
Consider Google Pay one of such payment apps. Other good examples are upcoming Apple Pay (when Safari implements the Payment Request API) or Samsung Pay. Alipay also implemented one and have done a talk about it at Google I/O 2017.
https://www.youtube.com/watch?v=hU89pPBmhds
What makes it look complicated about Google Pay for those who knew about the Payment Request API is that it conceals the Payment Request API behind its library. By initiating Payment Request with just a single payment method without requesting shipping information, you can bypass Payment Request user interface and directly launch the payment app (in this case Google Pay).
https://developers.google.com/payments/web/tutorial
This article should be a good start:
https://medium.com/dev-channel/addressing-common-misconceptions-about-the-payment-request-api-4d0db51dae75
Hope this helps.