Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Appearance settings
Discussion options

We’re exploring Appwrite Payments for Appwrite and want to understand if this is business-critical for you and which capabilities matter most.

I'd like to get a good understanding of how people use payments in their app.

  • What are you selling (SaaS, one-time, marketplace, usage-based)?
  • Is payments blocking your launch or growth? (If yes, how?)
  • Which top 3 features are must-have on day 1?
  • Which provider(s) and regions do you need?
  • Any compliance constraints (e.g., invoices with VAT, GST, Indian e-invoicing)?
  • Your stack (web/mobile/framework) & how you’d expect to integrate (SDK, webhooks, low-code UI).
  • Nice-to-haves you’d love but aren’t blockers.

Note: This thread is exploratory; we aren’t announcing timelines. Your input will directly influence scope and sequencing if we proceed. Interest in this thread will play a role of whether we potentially move forward or not.

Thank you all 👍

You must be logged in to vote

Replies: 3 comments · 3 replies

Comment options

I am building something for indian market which will have subscripotion and that too at 2 levels. One is platform subscription and another is AI subscription which is usage based. I would prefer SDK/webhook integratoin. Payment is defintely required for the launch. And YES it needs to be compliant with indian invoicing system including GST etc. I hope this helps

You must be logged in to vote
1 reply
@tessamero
Comment options

This helps a lot, thanks for sharing this @bhupesh-sf

Comment options

A subscription service sounds interesting! Depending on the timing, we might jump on board or use a different provider (for now), though.

  1. subscriptions and user-to-user
  2. launch no, growth yes (sponsorships are hard to get in Germany, but we're working stuff out as we go)
  3. modular subscriptions (they pay us), sending money (we pay them) and transferring money while keeping a handling fee (I'm not deep into legal stuff, but I could imagine some specialities there). All of the transactions have to be logged, filterable and exportable for our tax declaration.
  4. Paypal and Credit Card as international offers. Would love more regional stuff as well, like Wero and Klarna for (some of) EU
  5. pretty sure we'll need VAT. We haven't contacted any lawyers, yet, but will have a talk about that soon
  6. web-only during beta, then also mobile. We're currently on NextJS, but for mobile we'll have to use a different framework of course. I'd love a headless library (SDK) for TypeScript (client + server), Swift (client) and Kotlin (client).
  7. would love to have a Rust SDK (client + server) as well! I'm eying Dioxus for toy projects for now, but who knows, it might go places...
You must be logged in to vote
2 replies
@tessamero
Comment options

This is great feedback and definitely going to keep in mind as we potentially put together an RFC of what this would look like. If any other ideas come to mind, feel free to make more comments in this thread. :)

@minecrawler
Comment options

One more thing: My Appwrite Pro payments randomly fail, but when I retry them they go through. Maybe something to automate this would be great, like retry payments a few times (e.g. make it configurable so I can set it to try 3 times over 3h) before failing it. Not (just) talking about the Appwrite payment, but also about the new payment system :)

Comment options

Is there any movement on this?

Let us know if the PayPal Developers (@paypaldev) can help 👋

You must be logged in to vote
0 replies
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
💡
Ideas
Labels
None yet
4 participants
Morty Proxy This is a proxified and sanitized view of the page, visit original site.