BTCPay Forms (Form Builder) - Customizable checkout invoice

[pavlenex]

Is your feature request related to a problem? Please describe.

@Kukks and I brainstormed an idea a while ago about having customizable checkout pages. Leaving our ideas here for further discussion.

BTCPay Forms or Form Builder would be the app built-in into BTCPay that would allow users to create customizable checkouts and landing pages and gather information beyond default "refund email" that willl be parsed into invoice.

The use case:

1. E-commerce site uses pay button in store, (because they don't use CMS) and needs a more configurable way to ask for buyer address Request Buyer Address #505 and other relevant information in order to process the order.
   Our invoices are not customizable, in order to change something, a user needs to fork btcpay and perform a bunch of technical issues. Instead store owner can use btcpay forms and customize checkout steps and fields that would be offered before the invoice is shown.
2. The organization accepts the donation and needs customizable text fields at the checkout where the donor can give personal info, address, notes, instructions
3. People can create highly-customizable landing pages to accept donations, tips, etc.

Describe the solution you'd like
An app that would allow people to create customizable drag & drop forms, add fields that will parse information into an invoice.

Provide examples

Realated issues #671 #505 #862

[Liongrass]

I'd love something like that!

I'm mainly using html forms to create simple payment buttons, and I'd love to be able to easily add a line like <input type="text" name="Name" placeholder="Your Name"> to the <form> field
and see it populate the name field in 'buyer information' in mybtcpay.com/invoices

[royserpa]

I'd love something like that!

I'm mainly using html forms to create simple payment buttons, and I'd love to be able to easily add a line like <input type="text" name="Name" placeholder="Your Name"> to the <form> field
and see it populate the name field in 'buyer information' in mybtcpay.com/invoices

Currently, all data gathering is being done on my website. I don't think it's needed to fork an instance as is.

Sure, it would be "easier" to implement, but with the help of the url notification and email notification methods, one can create a nice funnel and use your site's databases to store client data.

I think the btcpayserver server should stay only for btcpayserver info only. And in your website, you store all client data as you wish.

[Liongrass]

With BTCPay Apps I can already run a store without a separate website or database, which is really powerful. But I'm limited to the email address as the sole identifier. With just a two more field (name, company) I could use BTCPay properly for ticketing for events, and with just a few more (address) I could use it as a fully grown store.

[JMadisonTP]

With BTCPay Apps I can already run a store without a separate website or database, which is really powerful. But I'm limited to the email address as the sole identifier. With just a two more field (name, company) I could use BTCPay properly for ticketing for events, and with just a few more (address) I could use it as a fully grown store.

I was thinking the as use case.
I have an idea for the team. When we create the products template. Can you add the extra "fields" in there. Such as name, email, address, and make them optional to deply for us merchants. Or even shirt or hat size. If the product template could be expanded to those fields when they confirm checkout could be.all we need.

[dennisreimann]

Some ideas and thoughts …

Merchant point of view:

• As an app it would be an option per store
• Per store there could be many of those apps for different use cases (e.g. landing pages)
• The app offers ways to extend the invoice with custom fields
• The form can be build and configured (field names, required/optional, etc.) using a builder like sketched above
• The configuration contains the fields as structured data and the form can be previewed
• Instead of directly linking to the checkout page, the user facing part of the app can be referenced

User's perspective:

• On checkout the user first lands on the user facing part of the app and sees the form
• The form also contains a hidden field with the reference of the actual invoice
• User submits the form, the app validates the fields and shows errors or redirects to the actual checkout page
• Invoices could be extended with a field that holds the custom data coming from the previous page
• Checkout page could display the custom data in a read-only form and allow to jump back and edit it before checkout
• User does the checkout and the custom data gets submitted

I like that it could be an optional addition and also that one would have the option to have multiple forms per store this way.
Not sure what's the best way to hold/pass on and store the custom data as I don't know the data structure of the invoices yet, but at least that's how I could imagine it.

[jonathanalevi]

Yes, please! The ability to at least collect first and last name would be game changing. I’d also like it to be in the same interface as the email collection, ideally right above the QR. I don’t like that they have to enter their email first and then it shows the QR...

[woutersamaey]

I will be introducing dynamic forms soon, which could be used as a stepping stone for this.

[123mitnik]

@woutersamaey this will be a game changer. Do you have ETA for dynamic forms release ?

[woutersamaey]

Basic classes are ready. I am proposing a PR in a few days where they will be used. I will be using them to build a config form for the Kraken Exchange plugin, which allows you to configure your API and Private Key as part of the new custodian API system.

[123mitnik]

this is great news ! and it will unlock a lot of new use cases if integrated inside the invoicing

[dennisreimann]

Update: This is happening with #4137