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?
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.
In my mobile app when the user has selected some items, I would like them to be able to review their order and see a preview of their bill (the price of each item, subtotal, taxes and total). However I would not want them to pay immediately. Once they place the order, they will not be charged until the order is accepted.
Do I calculate the user's subtotal, tax and total on my server or does stripe provide an api to handle these?
I've read the docs on invoicing and checkout, and checkout seems to be the api for my situation but I'm not 100% sure.
It depends on how you define "place the order" and "order is accepted". Normally when the Stripe's Checkout Session page is displayed to your customer and they push the "Pay" button, the transaction will be executed immediately (they paid), then the customer can be redirected back to your page or app.
If you want to somehow delay the payment until a specific timing (that you want to review or execute some logic, before eventually "accept" the order), you can consider using Checkout with Setup Intent.
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.
We have integrated the NodeJs bot application with the bot framework for interacting with bot in the Microsoft teams.
Based on the user input we are sending the adaptive cards respectively. Currently user can get the adaptive card today and can update the card later that day or after few days.
Is there any way to make the card expire after specific amount of time which make the card disabled.
Thank You
I have an idea how you could do this, but just an fyi that I've not done exactly this before, so there's no guarantee it will work. Basically, you'd be combining the ability to Update a message like discussed here with sending (or in this case 'updating') a pro-active message - see more here on that.
Because this is an existing conversation with the user, you'll have access from any existing message the user sends to get the parameters you need to start your proactive conversation (you need serviceurl, conversationid, tenantid, etc.). Do note that you can send a proactive message from OUTSIDE your bot (the code can be hosted somewhere else, and doesn't need to actually live IN your bot, even though to the user it will appear as if a proactive message was sent from your bot). I mention this because you could have this "expire card" message live in a separate process to your bot.
In case if you are still looking for an answer, I recently tried this approach:
In the card's response data, I set the expiry date and so now when the user submits the card, you can validate the data in the response and then update the card accordingly.
I had to use this approach because we have a very high user base and updating the card for all users proactively took much longer.
Cons: The card will remain will remain active, unless and until the user takes some action on it.
First of all, no this is nothing that is already implemented anywhere and you completely have to build that yourself.
One way to do this is this:
You need to store the activity / message ID for all cards you send. If you have the ID, you can always at any time go back and update the message (ie update your card)
Now that said, what i would suggest is this:
Sent a card to the user and store the id
Store the ID together
with creation date and expiration date somewhere on your end
Have some scheduled process that scans for expired cards
If a card is expired, update the message with a new card saying "sorry this card is expired"
We did that for our MS Teams Bot and its working quite well this way.
From what I understand, using the PayPal api, you can pass your payment amount by populating a hidden HTML input field which will be submitted to PayPal.
What I've got so far looks somewhat like this:
<input type="hidden" name="amount" value="60.00">
My question is - isn't this super unsafe? What's there to stop someone from changing the payment value in the element inspector for instance?
You may want to use PayPal ButtonManager API operation in order to programatically create, manage, edit, and delete PayPal Payment Standard buttons, which are the same kind of buttons that you can create from the PayPal Profile.
Hosted buttons created by this API reside on PayPal and can use all features, including inventory management; however, you can use this API to create code for non-hosted Standard buttons as well.
The button you will create from this API request will look like:
https://www.sandbox.paypal.com/cgi-bin/webscr?cmd=_s-xclick&hosted_button_id=19218
As you can see no values like "business", "amount" or others are visible and for this reason this would be a safe solution and personally I'd recommend it.
Back to your question "What's there to stop someone from changing the payment value in the element inspector for instance?"
We recommend to use API requests (see ExpressCheckout or ButtonManager to create Standard buttons) and Instant Payment Notifications service (IPN), which is a message service that notifies you of events related to PayPal transactions. You can use IPN messages to automate back-office and administrative functions, such as fulfilling orders, tracking customers, and providing status and other transaction-related information.