🚀 [Feature]: Support for payment via Webhook

[coderofsalvation]

Feature Description

this is the simplest payment provider: a webhook

Basically, this payment provider just returns a {payment: 'success'} status e.g.

Reason: in the broadsense a transactio/payment can also mean 'entitled to download'.
Imagine a transaction which requires a somebody starring a github project, liking a post e.g.
Or even fictional currencies like kudos per users (in a db elsewhere).
Using this generic payment webhook, various other integrations could become possible (even proxying to payment provider-integrations which run elsewhere)

Additional Context (optional)

No response

Code Snippet (optional)

No response

Checklist:

• I agree to follow litecart's Code of Conduct.
• I have checked for existing issues that describe my suggestion prior to opening this one.
• I understand that improperly formatted feature requests may be closed without explanation.

[shurco]

Hi,

If I understood you correctly, this functionality is quite labor-intensive.
Each payment system has its own webhook data format, so it is necessary to create a manual parsing form for webhook data.
If you provide examples of projects where this is implemented, I will consider this functionality.
But I would prefer not to complicate the project with fine-tuning.

[coderofsalvation]

Thanks for getting back to me.
Perhaps I'm explaining it too difficult, it's basically a dummy provider with freeform textfields:

So now, as a thought experiment, imagine replacing X with:

X	usecase	HTTP POST receiver	response
email	user can 'pay' with his/her email	newsletter system	{payment:true, info:"thank you for your email"}
githubstar	user can 'pay' by starring a repository	lambda/google scripts	{payment:true, info:"thank you, we've confirmed your star to our project"}
facebook like	user can 'pay' by liking a FB group	nodered/n8n/IFTTT	{payment:true, info:"thank you, we've confirmed your like"}
youtube like	user can 'pay' by liking a YT channel	nodered/n8n/IFTTT	{payment:true, info:"thank you, we've confirmed your like"}
crypto payment	user enters their wallet adress	lamdba/google scripts	{payment:true, info:"thank you, we've confirmed a payment from your wallet to ours"}
.......	literally anything which lives on the web	any future product/project

So the power in this lies into generic transactions, which the admin can define using an endpoint outside of litecart.
The problem with opensource paywalls like https://www.litecart.net/en is that they compete by offering the largest amount of established paymentproviders, which is very uninnovate for an opensource project imho.
For your litecart, I would take another approach, by combining UX simplicity (which you seem to have a lot of talent for) and
extensibility outside of litecart.

That would be a great angle for adoption imho, because for most people something like https://www.litecart.net/en is too much.

My userstory (and why I got attracted to your litecart) is: I sell music/samplepacks on gumroad (https://leondustar.gumroad.com/) but the thing is..I use like 1% of their features.
I just want a simple way to upload a file and sell it.
However, what I miss from their other 99% features is this: people without money can't pay.
This sounds stupid, but it's very important.
It turns out, a lot of my (musician) followers are not in a situation to pay due to harsh circumstances.
So why can't they pay with a like, a github star, an email etc?
There's no way I can reroute a gumroad paybutton to my own HTTP endpoint (where I can decide whether they are eligable to download).
With something like above, a whole universe of paymenttypes (which the admin can decide on) becomes possible by just one HTTP endpoint.

The reason why I'm trying to sell you this feature, is that I think Litecart could be an amazing opportunity to democratize paymenttypes: by offering a generic HTTP-endpoint payment.
I don't think commercial players like gumroad will support this, because they're bought by their paymentprovider(s) (to market their paymentsystem).
Just think about it, almost any paymentplatform is hardcoded/locked-in to paymentproviders.

ps. offtopic: you have beautiful emoji-commit messages..what software do you use to prefix them with emoji's?