7 ms·

Show HN: Small Transfers – charge from 0.000001 USD per request for your SaaS

198 points by strnisa 1y ago

Hi HN, I built Small Transfers, a payments platform for SaaS / API makers who want to bill customers per request instead of pushing them into subscriptions or pre-buy packages. *Why?* - Many customers hate subscriptions and/or want to use a service occasionally. - Traditional payment processors add a fixed fee to every charge, making charges below 1 USD impractical. - Stripe UBB tracks usage, but you still need to write your own auth, add spending limits, and each merchant charges cards separately (extra fees for customers). *How it works?* - Each merchant has a Small Transfers account linked to their Stripe account via Stripe Connect, which is used to transfer payouts to merchants. - Each customer has a Small Transfers account where we verify them using Google Sign-In, 3-D Secure, and Stripe Radar to minimise the chances of a customer not paying their balance. - Customers allow your service to identify and charge them via platform's own OAuth. This also removes the need for your service to implement its own auth. (Simple services don't even need their own database.) - Merchants call a simple REST API to authorize and capture a charge with a minimum amount of 0.000001 USD. Note that you can authorize more than you capture, allowing you to authorize the max amount your request might use, and then capture your actual cost plus margin (great for many use cases, e.g., AI). - The platform takes care of charging customers and sending payouts to merchants. - Merchants pay a flat 3% fee. Customers pay payment processing fees when they pay for their balance. There's a Next.js Starter project (https://github.com/smalltransfers/nextjs-starter https://github.com/smalltransfers/nextjs-starter) and a live demo (https://nextjs-starter.smalltransfers.com/ https://nextjs-starter.smalltransfers.com/). I've been dog-fooding the platform with my own service (https://unattach.com/ https://unattach.com/) and would love your feedback, specifically: - The general approach and whether there is anything I should do differently. - Any concerns and how I could mitigate them. - Any other feedback. I'm also looking for more merchants to try out the platform, and can help you with the integration. Thank you for your time! Happy to answer questions here.

deleted 1y ago
[deleted]
freakynit 1y ago
I had 100% same idea since a few months now. Didn't pursue it because of lack of companies and customers willing to use such a platform as intermediatory. Secondly, the legal aspect. Will this be considered as a wallet? Anyways, loved to see it implemented by someone.
- strnisa 1y ago
  You're right to consider this, as it's an important aspect from a legal perspective. Since Small Transfers doesn't store customers' funds or allow them to withdraw a balance, the platform is not considered an e-money institution or a "wallet". When the customers pay their balance, we immediately forward the funds to the merchants.
  - otterley 1y ago
    What happens when customers don't pay their balance? What happens when the charge attempt fails after initial preauth?
    - strnisa 1y ago
      Ultimately, the merchant bears the risk of non-payment, but the platform does its best, using industry-standard practices, to pre-check the customer and their payment methods for fraud and ensure a successful payment. If a merchant successfully authorizes a charge, the amount is reserved for that merchant for a limited period. Trying to capture that amount (or less) during this period will succeed.
      - otterley 1y ago
        I'm a little confused. Is Small Transfers not the merchant for the CC transaction? (Your website suggests Small Transfers is the merchant of record and then transfers funds to the seller.) If not, what's your role in the settlement process?
        1y ago
kolistivra 1y ago
Cool! Does it use crypto?
- strnisa 1y ago
  Thanks! Small Transfers uses its own system for tracking usage, which is settled through Stripe. No crypto, tokens, or wallets.
  - codedokode 1y ago
    Convenient - the government always can know who watched what.
    - blacksmith_tb 1y ago
      Hmm, but it's a bargain to stuff false data in there too, just pay tiny fractions of a cent to send them your My Little Pony watching habits mixed in?
      - 64718283661 1y ago
        The fake ones can be filtered out easily because the interaction and behavior is different
huem0n 1y ago
I've been wanting something like this for a long time. There's a lot of ways this could go wrong, but I hope it works. I'd especially love a video platform using this model. I can't afford patreon for every YouTube channel, but I'd love to pay 10¢ per hour of video watched.
- strnisa 1y ago
  Yes, Small Transfers can be used for pay-per-view or pay-per-minute billing models. The platform's biggest risk that I see is a customer defaulting after using a merchant's service. The platform currently mitigates that with Stripe Radar, 3-D Secure, and spending caps, but I'm keen to hear anything specific you're thinking about.
  - cedws 1y ago
    I don’t know if it defeats the purpose but you could require an upfront, refundable deposit.
    - strnisa 1y ago
      Requiring money upfront would classify the platform as an e-money institution, which is highly problematic from the legal perspective.
      - jazzyjackson 1y ago
        How does tarsnap handle it? I think there's lots of services that bill up front... Isn't it only e-money if you can convert it back to cash?
        strnisa 1y ago
        If you store funds for a specific service that you provide, it's fine. If it's for many services or services provided by others, it's legally problematic.
ed 1y ago
I mean this in the most constructive way possible: why do you think this idea hasn’t worked before, when it’s been fairly obvious and easy to build for a long time? And what’s your fix for that issue? You present the merchant side of things, but not the customer side which is more important to me, as a potential Small transfers adopter. What’s customer conversion like? Are micropayments actually better than typical payment amounts? Based on my experience I’d expect the conversion rate of a $0.01 and $1 fee to be pretty similar. The friction of inputting a credit card and trusting a service is way higher than the actual payment amount. I’d also have to introduce 2 more services to my customers: Small transfers powered by stripe, and customers would have to fund an account that realistically speaking can’t be used anywhere other than my site. Just offering some questions to think about!
- strnisa 1y ago
  I believe the idea has been attempted many times before, primarily by large companies that have tried to create their own currency. It seems deceptively simple, but it's quite tricky to get right, both from a legal and technical perspective. One of the main legal complications is the one mentioned in another comment: avoiding the status of an e-money institution. With Small Transfers: - There is no wallet or funding for the account. Customers simply pay for what they owe, usually at the end of each month. - There is a lower psychological barrier, since there is no subscription or prepay commitment. Customers who dislike recurring payments are more willing to try something new that avoids this. - Merchants need to introduce customers to just one extra service, Small Transfers. Some customers of Unattach (a service I built) are happily paying for the service via Small Transfers, and early feedback shows that they really appreciate this pricing model. It's worth noting that Unattach also supports the classic subscription model. As more merchants adopt Small Transfers, customers will still only need one account, making micro-billing even more convenient.
- drewp 1y ago
  https://en.wikipedia.org/wiki/Flattr https://en.wikipedia.org/wiki/Flattr figured out some parts of this. Notably, you picked your own total monthly donation, and then clicked a button on participating sites to allocate a fraction of your total to them. AFAICT it worked as advertised, but raised new issues with donation behavior. E.g. I obviously like curl every month, so should I click its button monthly? Twice monthly? If I am a developer of some other useful OSS software, should I click curl's button and the curl devs click my button? Does the money just slosh around between merchant-customers? Is that good?
PhilippGille 1y ago
I think micropayments are important for a healthy web economy. In 2018 I built a pay-per-call API paywall using the Lightning Network (a Bitcoin Layer 2 protocol/network that enables instant, low-fee payments): https://github.com/philippgille/ln-paywall https://github.com/philippgille/ln-paywall But most people are either unwilling to touch crypto at all, or holding on to it tightly as investment and not willing to use as payment. So I wish you luck to make this work in the fiat world!
- strnisa 1y ago
  Nice work and thank you for the encouraging words!
- deleted 1y ago
  [deleted]
petertodd 1y ago
Why would you use this over Bitcoin Lightning payments?
- Spivak 1y ago
  Because it works with a credit card? Also unless you do what this service is doing by accumulating payments until a reasonable threshold is reached before actually charging the fees then even on Lightning will eat you alive. So if you have the system to handle billing this way you might as well use existing payment networks.
- yieldcrv 1y ago
  unsecured lending in the crypto world is nonexistent or implodes immediately, and even more nonexistent in the bitcoin side of things credit cards solve that market need and are wildly popular for decades
  - beeflet 1y ago
    I think credit cards succeed because they give customers rewards, passing on the cost to the vendor and ultimately all other customers. Also because they were the only alternative to cash for the longest time
    - yieldcrv 1y ago
      that's an additional attraction many crypto services give passive fungible rewards to users for volume too, and they are wildly popular in that ecosystem most large and growing platforms onchain do that, and people farm them hoping they begin doing that as they reward earliest users, later
fastest963 1y ago
What's the payment threshold? I assume you're paying 2.9% and $0.30 (or around there) for the transaction. You charge that to the customer but what if their bill is $0.01, are you really going to make them pay $0.32 for $0.01 of usage? How do you expect SaaS providers to communicate that on their pricing page? If they charge $0.01 per request and the end-user makes 100 requests their bill is actually $1.33 which means the actual per-request charge is $0.0133. Several years ago Stripe offered more favorable pricing for small transactions but it's my understanding that that pricing is no longer available to new Stripe businesses.
- strnisa 1y ago
  If a customer's balance is under $1 at the end of the month, we delay charging them for up to 60 days and send email reminders. If it's still under $1 after 60 days, we charge at least $0.50 and credit the difference (after fees) to their account for future use.
  - soared 1y ago
    Good use case for stablecoin/crypto through stripe
up2isomorphism 1y ago
If I need this I don’t deserve to survive in the SaaS business.
anonymous344 1y ago
nice idea. Web3 was supposed to solve this (by skipping visa/mastercard/paypal's crazy fees) still waiting..
Roguelazer 1y ago
Some API questions/observations - I don't see an idempotency key in the request to authorize a charge; that might be something nice for people looking to build reliable systems on this. - How long are accessTokens valid? Forever? Do they become invalid if the subject metadata (firstName, lastName, email) changes? I think this is a super-cool idea, but I think the idea of extending net30 terms to every customer of some B2C product seems pretty iffy; since you're deferring charging until the end of the month, you won't get most of the fraud signals from Stripe until then and anything popular that used this system seems like it'd be pretty inundated with fraud. I would at least consider doing the charges more frequently (i.e., charge at the end of the month or every $50, whichever comes first) to put a better bound on how long you can go before finding out that someone gave you a stolen card.
- freakynit 1y ago
  A better model I had in mind works like this: customers purchase tokens in any amount they choose. Companies then charge for their services using these tokens through the platform's APIs. At the end of each month, settlements are made based on the total token value. The smallest token unit could be as small as one-millionth of a dollar. It’s similar to a digital wallet, but without currency conversion: customers cannot exchange tokens back into money.
  - strnisa 1y ago
    That approach generally doesn't work from a legal perspective: prepaid tokens are often treated as e-money (especially if it's not for company's own products or services), and in many jurisdictions, holding value for users requires an e-money/money transmitter license.
    - ta12653421 1y ago
      In EU, this depends mainly on the question of exchange/interchangeability: If you sell them as vouchers and do not allow redeeming/payout in the original cash, its not a problem.
Gienoz100 1y ago
[dead]
smoyer 1y ago
Interesting ... A web2 equivalent to the x402 specification. Thanks for the explanation of how fees are handled below. https://x402.org https://x402.org
- strnisa 1y ago
  x402: on-chain, HTTP 402, wallet-to-server, synchronous per-request payments. Small Transfers: card rails (Stripe), account-based, off-session, batched billing with spend caps; no tokens/wallets.
more_corn 1y ago
This could be a great way to charge ai for access to content.
- strnisa 1y ago
  Definitely! The API lets you authorize the maximum your AI request might cost (+ margin), then capture the actual cost (+ margin). For some example code, see our Next.js Starter project: https://github.com/smalltransfers/nextjs-starter https://github.com/smalltransfers/nextjs-starter
- strnisa 1y ago
  I misunderstood this comment originally. In principle, Small Transfers (ST) could let a content site bill AI agents per request. Each site (acting as an ST merchant) would expose a simple "content" endpoint. The AI agent (as an ST customer) would perform a headless OAuth flow, after which the content site could charge for access. We currently don't support headless OAuth, but if anyone is interested in exploring this use case, please get in touch.
nprateem 1y ago
And as someone building an app I do want subscriptions for all the reasons everyone knows about. That's probably why no one really does this despite being talked about for years.
- strnisa 1y ago
  Subscriptions are great for predictability, and most apps should keep them. Small Transfers can be added to help with: - users who dislike subscriptions - infrequent users - reducing/removing free-trial costs for non-converting users A common pattern is hybrid pricing: pay-as-you-go (PAYG) for light/occasional use, a subscription for regular use. Similar to mobile plans, where monthly plans become cheaper above a certain usage threshold. I use this pattern for one of my services: https://unattach.com/pricing https://unattach.com/pricing I believe that Small Transfers also enables services that aren't viable with subscriptions or prepaid credits, e.g., a movie-suggestion service.
felipe-pathwave 1y ago
That's a very cool idea! To me the main barrier of adoption would be asking my users to create an account with a 3rd party provider in order to be able to pay me. That's a lot of added friction and I'd be afraid of the impact this would have on conversion rates. Wouldn't it be possible to embed your solution on my website so the user just adds their Credit Card once then gets properly billed from there?
- strnisa 1y ago
  You're correct that this adds a barrier to entry, but for many users, that hurdle is still lower than asking them to start a subscription or buy a prepaid bundle. We plan to provide the classic "Google Sign-In" style pop-up window instead of a redirect. Research indicates that it can increase conversion by approximately 5-10%. Additionally, we are considering a white-label onboarding flow. If the merchant provides proof of customer identity, we can also skip the sign-in step. Both of these should help improve conversion rates. A fully embedded solution is possible, but it would require the merchant to collect the customer's card details on Small Transfers' behalf (using Small Transfers' Stripe publishable key), which complicates things from both implementation and legal perspectives.
  - felipe-pathwave 1y ago
    Cool! I've added you on linkedin I'd love to chat more about this
d--b 1y ago
I'll probably use your unattach service soon (gmail keeps bugging me about being 98% full). Your pricing is a bit weird though. For a $9 subscription a year, I might as well upgrade my gmail storage to 100gb. The pay-as-you-go is $0.01 per email, but I don't know how many emails with attachment I have in there. Gmail only tells me of "many". Could be tens of thousands... I have no idea... I have 250 emails with attachment since June, so a bit less than 100 per month, and I 've had that inbox since 2004 ish. So conservatively, I have 1200 emails a year, so about 25k emails to clean up. So that would be a one time fee of $24. But perhaps much less because attachments were rarer back then. But I could also pay a one year subscription. Only use it once to clean up the whole thing, and then cancel and come back the next time I need it, like in 5 years. But yeah, I don't really want to do that, cause I don't want to forget that it's a subscription... What I would like is a usage-based price, that's based off the inbox size in gb and that's quite cheaper than upgrading my gmail. So maybe cleaning 15gb for $15 would be great. Or maybe $2 for each gb that's freed (I wouldn't know how much exactly that would cost, but I know it'd less that $30).
- strnisa 1y ago
  I understand not wanting another subscription. You can subscribe and then immediately turn off auto-renewal — your access stays active for the full year you paid for. On PAYG, you can target the largest emails first and stop whenever you've freed enough space. For example, processing 300 of the largest emails at $0.01 each is about $3; if they average around 10 MB, that's 3 GB freed.

198 points by strnisa 1y ago

deleted 1y ago

[deleted]

freakynit 1y ago

I had 100% same idea since a few months now. Didn't pursue it because of lack of companies and customers willing to use such a platform as intermediatory. Secondly, the legal aspect. Will this be considered as a wallet? Anyways, loved to see it implemented by someone.

strnisa 1y ago
You're right to consider this, as it's an important aspect from a legal perspective. Since Small Transfers doesn't store customers' funds or allow them to withdraw a balance, the platform is not considered an e-money institution or a "wallet". When the customers pay their balance, we immediately forward the funds to the merchants.
- otterley 1y ago
  What happens when customers don't pay their balance? What happens when the charge attempt fails after initial preauth?
  - strnisa 1y ago
    Ultimately, the merchant bears the risk of non-payment, but the platform does its best, using industry-standard practices, to pre-check the customer and their payment methods for fraud and ensure a successful payment. If a merchant successfully authorizes a charge, the amount is reserved for that merchant for a limited period. Trying to capture that amount (or less) during this period will succeed.
    - otterley 1y ago
      I'm a little confused. Is Small Transfers not the merchant for the CC transaction? (Your website suggests Small Transfers is the merchant of record and then transfers funds to the seller.) If not, what's your role in the settlement process?
      - 1y ago

kolistivra 1y ago

Cool! Does it use crypto?

strnisa 1y ago
Thanks! Small Transfers uses its own system for tracking usage, which is settled through Stripe. No crypto, tokens, or wallets.
- codedokode 1y ago
  Convenient - the government always can know who watched what.
  - blacksmith_tb 1y ago
    Hmm, but it's a bargain to stuff false data in there too, just pay tiny fractions of a cent to send them your My Little Pony watching habits mixed in?
    - 64718283661 1y ago
      The fake ones can be filtered out easily because the interaction and behavior is different

huem0n 1y ago

I've been wanting something like this for a long time. There's a lot of ways this could go wrong, but I hope it works. I'd especially love a video platform using this model. I can't afford patreon for every YouTube channel, but I'd love to pay 10¢ per hour of video watched.

strnisa 1y ago
Yes, Small Transfers can be used for pay-per-view or pay-per-minute billing models. The platform's biggest risk that I see is a customer defaulting after using a merchant's service. The platform currently mitigates that with Stripe Radar, 3-D Secure, and spending caps, but I'm keen to hear anything specific you're thinking about.
- cedws 1y ago
  I don’t know if it defeats the purpose but you could require an upfront, refundable deposit.
  - strnisa 1y ago
    Requiring money upfront would classify the platform as an e-money institution, which is highly problematic from the legal perspective.
    - jazzyjackson 1y ago
      How does tarsnap handle it? I think there's lots of services that bill up front... Isn't it only e-money if you can convert it back to cash?
      - strnisa 1y ago
        If you store funds for a specific service that you provide, it's fine. If it's for many services or services provided by others, it's legally problematic.

ed 1y ago

I mean this in the most constructive way possible: why do you think this idea hasn’t worked before, when it’s been fairly obvious and easy to build for a long time? And what’s your fix for that issue? You present the merchant side of things, but not the customer side which is more important to me, as a potential Small transfers adopter. What’s customer conversion like? Are micropayments actually better than typical payment amounts? Based on my experience I’d expect the conversion rate of a $0.01 and $1 fee to be pretty similar. The friction of inputting a credit card and trusting a service is way higher than the actual payment amount. I’d also have to introduce 2 more services to my customers: Small transfers powered by stripe, and customers would have to fund an account that realistically speaking can’t be used anywhere other than my site. Just offering some questions to think about!

strnisa 1y ago
I believe the idea has been attempted many times before, primarily by large companies that have tried to create their own currency. It seems deceptively simple, but it's quite tricky to get right, both from a legal and technical perspective. One of the main legal complications is the one mentioned in another comment: avoiding the status of an e-money institution. With Small Transfers: - There is no wallet or funding for the account. Customers simply pay for what they owe, usually at the end of each month. - There is a lower psychological barrier, since there is no subscription or prepay commitment. Customers who dislike recurring payments are more willing to try something new that avoids this. - Merchants need to introduce customers to just one extra service, Small Transfers. Some customers of Unattach (a service I built) are happily paying for the service via Small Transfers, and early feedback shows that they really appreciate this pricing model. It's worth noting that Unattach also supports the classic subscription model. As more merchants adopt Small Transfers, customers will still only need one account, making micro-billing even more convenient.
drewp 1y ago
https://en.wikipedia.org/wiki/Flattr https://en.wikipedia.org/wiki/Flattr figured out some parts of this. Notably, you picked your own total monthly donation, and then clicked a button on participating sites to allocate a fraction of your total to them. AFAICT it worked as advertised, but raised new issues with donation behavior. E.g. I obviously like curl every month, so should I click its button monthly? Twice monthly? If I am a developer of some other useful OSS software, should I click curl's button and the curl devs click my button? Does the money just slosh around between merchant-customers? Is that good?

PhilippGille 1y ago

I think micropayments are important for a healthy web economy. In 2018 I built a pay-per-call API paywall using the Lightning Network (a Bitcoin Layer 2 protocol/network that enables instant, low-fee payments): https://github.com/philippgille/ln-paywall https://github.com/philippgille/ln-paywall But most people are either unwilling to touch crypto at all, or holding on to it tightly as investment and not willing to use as payment. So I wish you luck to make this work in the fiat world!

strnisa 1y ago
Nice work and thank you for the encouraging words!
deleted 1y ago
[deleted]

petertodd 1y ago

Why would you use this over Bitcoin Lightning payments?

Spivak 1y ago
Because it works with a credit card? Also unless you do what this service is doing by accumulating payments until a reasonable threshold is reached before actually charging the fees then even on Lightning will eat you alive. So if you have the system to handle billing this way you might as well use existing payment networks.
yieldcrv 1y ago
unsecured lending in the crypto world is nonexistent or implodes immediately, and even more nonexistent in the bitcoin side of things credit cards solve that market need and are wildly popular for decades
- beeflet 1y ago
  I think credit cards succeed because they give customers rewards, passing on the cost to the vendor and ultimately all other customers. Also because they were the only alternative to cash for the longest time
  - yieldcrv 1y ago
    that's an additional attraction many crypto services give passive fungible rewards to users for volume too, and they are wildly popular in that ecosystem most large and growing platforms onchain do that, and people farm them hoping they begin doing that as they reward earliest users, later

fastest963 1y ago

What's the payment threshold? I assume you're paying 2.9% and $0.30 (or around there) for the transaction. You charge that to the customer but what if their bill is $0.01, are you really going to make them pay $0.32 for $0.01 of usage? How do you expect SaaS providers to communicate that on their pricing page? If they charge $0.01 per request and the end-user makes 100 requests their bill is actually $1.33 which means the actual per-request charge is $0.0133. Several years ago Stripe offered more favorable pricing for small transactions but it's my understanding that that pricing is no longer available to new Stripe businesses.

strnisa 1y ago
If a customer's balance is under $1 at the end of the month, we delay charging them for up to 60 days and send email reminders. If it's still under $1 after 60 days, we charge at least $0.50 and credit the difference (after fees) to their account for future use.
- soared 1y ago
  Good use case for stablecoin/crypto through stripe

up2isomorphism 1y ago

If I need this I don’t deserve to survive in the SaaS business.

anonymous344 1y ago

nice idea. Web3 was supposed to solve this (by skipping visa/mastercard/paypal's crazy fees) still waiting..

Roguelazer 1y ago

Some API questions/observations - I don't see an idempotency key in the request to authorize a charge; that might be something nice for people looking to build reliable systems on this. - How long are accessTokens valid? Forever? Do they become invalid if the subject metadata (firstName, lastName, email) changes? I think this is a super-cool idea, but I think the idea of extending net30 terms to every customer of some B2C product seems pretty iffy; since you're deferring charging until the end of the month, you won't get most of the fraud signals from Stripe until then and anything popular that used this system seems like it'd be pretty inundated with fraud. I would at least consider doing the charges more frequently (i.e., charge at the end of the month or every $50, whichever comes first) to put a better bound on how long you can go before finding out that someone gave you a stolen card.

freakynit 1y ago
A better model I had in mind works like this: customers purchase tokens in any amount they choose. Companies then charge for their services using these tokens through the platform's APIs. At the end of each month, settlements are made based on the total token value. The smallest token unit could be as small as one-millionth of a dollar. It’s similar to a digital wallet, but without currency conversion: customers cannot exchange tokens back into money.
- strnisa 1y ago
  That approach generally doesn't work from a legal perspective: prepaid tokens are often treated as e-money (especially if it's not for company's own products or services), and in many jurisdictions, holding value for users requires an e-money/money transmitter license.
  - ta12653421 1y ago
    In EU, this depends mainly on the question of exchange/interchangeability: If you sell them as vouchers and do not allow redeeming/payout in the original cash, its not a problem.

Gienoz100 1y ago

[dead]

smoyer 1y ago

Interesting ... A web2 equivalent to the x402 specification. Thanks for the explanation of how fees are handled below. https://x402.org https://x402.org

strnisa 1y ago
x402: on-chain, HTTP 402, wallet-to-server, synchronous per-request payments. Small Transfers: card rails (Stripe), account-based, off-session, batched billing with spend caps; no tokens/wallets.

more_corn 1y ago

This could be a great way to charge ai for access to content.

strnisa 1y ago
Definitely! The API lets you authorize the maximum your AI request might cost (+ margin), then capture the actual cost (+ margin). For some example code, see our Next.js Starter project: https://github.com/smalltransfers/nextjs-starter https://github.com/smalltransfers/nextjs-starter
strnisa 1y ago
I misunderstood this comment originally. In principle, Small Transfers (ST) could let a content site bill AI agents per request. Each site (acting as an ST merchant) would expose a simple "content" endpoint. The AI agent (as an ST customer) would perform a headless OAuth flow, after which the content site could charge for access. We currently don't support headless OAuth, but if anyone is interested in exploring this use case, please get in touch.

nprateem 1y ago

And as someone building an app I do want subscriptions for all the reasons everyone knows about. That's probably why no one really does this despite being talked about for years.

strnisa 1y ago
Subscriptions are great for predictability, and most apps should keep them. Small Transfers can be added to help with: - users who dislike subscriptions - infrequent users - reducing/removing free-trial costs for non-converting users A common pattern is hybrid pricing: pay-as-you-go (PAYG) for light/occasional use, a subscription for regular use. Similar to mobile plans, where monthly plans become cheaper above a certain usage threshold. I use this pattern for one of my services: https://unattach.com/pricing https://unattach.com/pricing I believe that Small Transfers also enables services that aren't viable with subscriptions or prepaid credits, e.g., a movie-suggestion service.

felipe-pathwave 1y ago

That's a very cool idea! To me the main barrier of adoption would be asking my users to create an account with a 3rd party provider in order to be able to pay me. That's a lot of added friction and I'd be afraid of the impact this would have on conversion rates. Wouldn't it be possible to embed your solution on my website so the user just adds their Credit Card once then gets properly billed from there?

strnisa 1y ago
You're correct that this adds a barrier to entry, but for many users, that hurdle is still lower than asking them to start a subscription or buy a prepaid bundle. We plan to provide the classic "Google Sign-In" style pop-up window instead of a redirect. Research indicates that it can increase conversion by approximately 5-10%. Additionally, we are considering a white-label onboarding flow. If the merchant provides proof of customer identity, we can also skip the sign-in step. Both of these should help improve conversion rates. A fully embedded solution is possible, but it would require the merchant to collect the customer's card details on Small Transfers' behalf (using Small Transfers' Stripe publishable key), which complicates things from both implementation and legal perspectives.
- felipe-pathwave 1y ago
  Cool! I've added you on linkedin I'd love to chat more about this

d--b 1y ago

I'll probably use your unattach service soon (gmail keeps bugging me about being 98% full). Your pricing is a bit weird though. For a $9 subscription a year, I might as well upgrade my gmail storage to 100gb. The pay-as-you-go is $0.01 per email, but I don't know how many emails with attachment I have in there. Gmail only tells me of "many". Could be tens of thousands... I have no idea... I have 250 emails with attachment since June, so a bit less than 100 per month, and I 've had that inbox since 2004 ish. So conservatively, I have 1200 emails a year, so about 25k emails to clean up. So that would be a one time fee of $24. But perhaps much less because attachments were rarer back then. But I could also pay a one year subscription. Only use it once to clean up the whole thing, and then cancel and come back the next time I need it, like in 5 years. But yeah, I don't really want to do that, cause I don't want to forget that it's a subscription... What I would like is a usage-based price, that's based off the inbox size in gb and that's quite cheaper than upgrading my gmail. So maybe cleaning 15gb for $15 would be great. Or maybe $2 for each gb that's freed (I wouldn't know how much exactly that would cost, but I know it'd less that $30).

strnisa 1y ago
I understand not wanting another subscription. You can subscribe and then immediately turn off auto-renewal — your access stays active for the full year you paid for. On PAYG, you can target the largest emails first and stop whenever you've freed enough space. For example, processing 300 of the largest emails at $0.01 each is about $3; if they average around 10 MB, that's 3 GB freed.