Almost never worked with a stripe.
Once I solved the problem with payment and that's it.
There is a site on which the user orders some stuff. Well, for payment - he attaches his card. Where the Stripe error is popping up with the text: "Customer cus_* already has the maximum number of payment methods attached."
why is this happening? Is there a maximum reached and what is it? how can i get rid of this error?
You are seeing this error message, maximum number of payment methods attached as there is a limit on how many payment methods can be attached to a specific customer. There are limits for cards and for sources.
To correct this, you can remove some of the existing payment methods from that customer. Moving forward, you can periodically detach payment methods that are older or won't need to be used again in your integration.
Related
I am implementing the Stripe payment platform using JavaScript and the PHP SDK.
I don't have any issues with the implementation itself, but I am not sure whether I have to reuse an existing PaymentIntent or it's perfectly fine to have a bunch of them created and incomplete.
I searched for this in Stripe's documentation, but I can't seem to find anything related to this.
For example, in my test account I have this:
It's all for the same transaction, because I was changing some visuals and refreshing the browser.
I am aware that each PaymentIntent has an ID, but is it recommended to add it as a query parameter and retrieve it on refreshing, or is it better to always generate a new Payment Intent.
My main reasoning is to avoid having a huge collection of incomplete payment intents.
The default integration path for Stripe today is to create a PaymentIntent first so that you get a client_secret you can use client-side to render their UI via PaymentElement. This means that if your customers decide not to pay after all, you end up with an incomplete PaymentIntent which is expected.
This is not really a problem, other than appearing in the Payments list which can be confusing. You could also write a background job daily that would cancel any PaymentIntent via you know won't be completed because the customer left and you didn't have any data to contact them to upsell them for example but this isn't really needed.
Stripe also has a beta (docs) right now (Feb 2023) that changes the default integration path. This simplifies the experience because you can render the PaymentElement client-side with specific options such as amount and currency. You'd then only create the PaymentIntent at the end of the flow
when the customer is attempting to pay. That flow limits the number of incomplete PaymentIntents since you only create them when the customer really pays. You'd still get some, for example after a decline by the customer's bank though.
I'm using the PaymentElement UI component to accept Stripe payments, which seems to be the way they're encouraging most people to go.
The docs say it "Automatically adjusts input fields to collect information based on the payment method and country... [and] Reduces friction for card payments with input validation, masking, styling and error handling."
The problem I'm having is that scrolling list of supported cards includes icons for cards which are not, in fact, supported in my region. And if someone enters one of those cards, it correctly identifies the icon, but doesn't throw a validation error — it waits until form submission and then fails to charge the card.
From a UX perspective, this seems less than ideal. OK, I get that 3056930009020004 correctly "validates" as a Diners Club card, but it seems that it should invalidate it in advance rather than waiting to actually try and complete the charge and responding with a "Your card is not supported" charge failure.
Is there a way I can (ideally) tell it to only include the cards that are actually supported automatically, or (alternatively) provide a list of cards it should display and validate?
If "no" to both of those, is this a bug? Can/should I report it as a bug or feature request to Stripe?
The steps below illustrate my problem with Stripe's PaymentIntent flow, but you could come up with something similar for the other payment gateways I've looked at where the final notification of a successful payment is sent asynchronously from the payment gateway to the merchant site.
Customer adds 10 x item A to their shopping cart, total now $100
Customer goes to checkout page. Server creates a Stripe PaymentIntent for the $100 total and sends the 'client_secret' to the browser.
Customer's browser displays the checkout page, showing $100 total, and Stripe's payment form.
Customer opens a new tab, and adds 10 x item B to their shopping cart, total now $200.
Customer returns to checkout tab, and completes $100 payment with Stripe (nothing the site can do to prevent this - it's all happening client side)
Asynchronously, Stripe notifies the site via webhooks that we've got a $100 payment. What do we do now?
The payment total no longer matches the cart total. Do we have to refund the payment and cancel the order? How do we notify the customer? We've probably already shown them an 'order complete - thank you' page, because we had no way of knowing the total was wrong until the asynchronous notification arrived. The customer's probably left our site already. What do we do with their shopping cart?
-- Some further background to all this:
I used to always turn to Stripe whenever my clients wanted to take online payments on their websites, because Stripe's synchronous model made my code nice and easy. The customer would enter their card details, Stripe would then return a token representing the payment, finally my server side code would check all the details were correct, use Stripe's API to collect the money, and return a 'thank you' message to the customer's browser.
But now it seems Stripe are moving away from this model to an asynchronous model (PaymentIntents), where your server is supposed to listen for notifications for completed payments, before fulfilling orders. In Stripe's terminology, we should set up 'webhooks' listening for the 'payment_intent.succeeded' event.
All the other payment gateways I've used in the past also have an asynchronous model, in the sense that your webserver has to wait for some kind of callback from the gateway notifying us of the payment, before we can safely start processing the order. PayPal calls it 'Instant Payment Notification', Worldpay called it 'Order Webhooks', Adflex called it 'Server2ServerNotification'... etc.
Where I'm struggling, is trying to cope with things that might happen during the gap between checkout starting, and payment notification being received. Given that these payment gateways are all using these kind of asynchronous models, there must be a simple solution to this (and similar) problems, but I'm really stuck - any suggestions would be much appreciated.
I think the main point you're missing here is that the PaymentIntent amount is set server-side. This means that when your customer opens a new tab and adds more items to their cart, you should be updating the PaymentIntent on your server to reflect the new amount. Then when they switch back to the other tab and complete the payment, you should have the total amount reflected in your PaymentIntent.
Your customer might still see the checkout process for an amount different to what is actually being charged, in which case I suggest you look at implementing websockets to make sure they always see the total amount in their shopping cart.
One of our customers triggered a "Your card has insufficient funds." error during card registration (we only issue a charge at a later time) and we weren't able to show a helpful error message because we didn't have a localization for this error. While my sibling-question Show (localized) payment source registration errors directly in Stripe Elements tries to work around the issue by avoiding to have to display the error at all, there are other places in our payment flow where our backend has to deal with payment errors (e.g. to send the user a mail stating the reason for the payment failure).
Is it possible to get a localized error text from stripe or is there a complete list of possible error codes so we can localize the messages ourselves? (We are using the stripe ruby gem, if that is of relevance.)
This gem might be useful for you here: https://github.com/ekosz/stripe-i18n
My problem is, the amount will differ every cycle but in recurring I have to pass only one fix amount which is depend on customers how they use our service.
I read reference transaction doc but i didn't got whole point.
I don't have any problem with manage from my side and set charge to user dynamically by my side but how it will work.
Paypal is not providing metered billing concept. For that I have use STRIPE later that time.