🚀 [Feature]: Support for payment via Webhook

coderofsalvation commented 8 months ago

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:

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

shurco commented 8 months ago

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 commented 8 months ago

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?

shurco / litecart