#nielsen_best-practices
steel prismBOT
👋 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/1416087018970026036
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
left jay
Hi, that is up to you. Many businessed use the hosted invoice page for convenience. Can you share more about your business use case and your specific concerns so we can talk through these?
steel prismBOT
halcyon vector
Yes, so we have our own frontend and backend where we use stripe to collect payments through the Stripe Payment Intent API. Customers can also send payments through checks. So what I wonder is, what are the implications** when Customers make payments through our portal or send checks, if an existing invoice page exists? Does that invoice need to be voided? or set as paid out of band?
drifting trellis
Hi there,
taking over for my colleague who had to step away.
When a customer pays an existing Invoice through a different channel, like checks, the correct way is to mark the Invoice as "paid out of band". https://support.stripe.com/questions/marking-an-invoice-paid-out-of-band
halcyon vector
i read that Invoices have an associated payment intent, but right now when a customer logs into our portal, that integration makes a new payment intent. Will we have to update that flow to instead check for an existing invoice and use it's payment intent? or can we still keep that flow, and mark the invoice either void or paid out of band?
drifting trellis
Yes, when you create an Invoice it automatically also creates an "underlying" Payment Intent too.
halcyon vector
ok so you would recommend changing the flow then?
drifting trellis
Yes, otherwise you would eventually create duplicate Payment Intent, correct?
halcyon vector
Right, and I suppose that might look weird in the reports. I was hoping perhaps voiding the invoice or just setting the invoice to paid out of band would be ok.
drifting trellis
Yes and would also create a false picture for the customer who would seem to have an open payment obligation with you.
halcyon vector
Gotcha. I'm wondering then if it's just easier for us to go with payment links. We really just want a quick way for a customer to click a link and make a payment without having to log in. A type of "Guest" payment
drifting trellis
Yes, Payment Links sound like the right option in this case.
halcyon vector
I'm looking at the payment link I just created. Is it possible to customize this? Ideally we could be able to remove "powered by stripe"
drifting trellis
You can create a "buy button" that you can customize https://docs.stripe.com/payment-links/buy-button
halcyon vector
that would require us to create a page and embed the button correct?
drifting trellis
Yeah, sorry I assumed we are talking about a website but I realize that is of course not necessarily true. I got confues by the button you just shared. Because the Payment Link will just be a shareable link that leads to a checkout session.
halcyon vector
right, another thing I'm looking at is I get an error when I set this parameter
We use skip verificaiton currently in our integration. This parameter works when we create an invoice but not when I create a payment link.
com.stripe.exception.InvalidRequestException: Received unknown parameter: payment_method_options. Did you mean payment_method_collection?; code: parameter_unknown; request-id: req_nBzguEjDRhvhHN
at com.stripe.net.LiveStripeResponseGetter.handleApiError(LiveStripeResponseGetter.java:246)
at com.stripe.net.LiveStripeResponseGetter.handleError(LiveStripeResponseGetter.java:207)
at com.stripe.net.LiveStripeResponseGetter.request(LiveStripeResponseGetter.java:105)
at com.stripe.model.PaymentLink.create(PaymentLink.java:301)
at com.stripe.model.PaymentLink.create(PaymentLink.java:285)
at CreateCustomPayment.main(CreateCustomPayment.java:49)
11:31:36 AM: Execution finished ':CreateCustomPayment.main()'.
drifting trellis
Let me take a quick look at this
I see, the parameter you are passing in payment_method_options does not exist on the Payment Link object.
halcyon vector
ok so skip verification is not supported at all for a payment link page?
drifting trellis
I am trying to find some information about this because it doesn't appear that way. But I want to make sure.
halcyon vector
This is a nonstandard param and we had to go through our account rep to get this to work, we have it working with payment intent in production and in testing it works for invoice api as well
drifting trellis
Yeah I know, it's a private preview feature at the moment. I am looking at the internal API docs and can't find any parameter that would match. But I am also going through our internal documentation for the feature at the moment to make sure I don't miss anything.
Ok sorry for the delay. I can confirm that there is no direct way to skip verififcation when using Payment Link. There are workarounds but they require custom implementation that goes far beyond a shareable link.
halcyon vector
I see ok, that's helpful in determining whether we should use this or an invoice.
I appreciate your help
drifting trellis
No worries. Always happy to help.