DEV Community: NodeX

Stripe or PayPal would be my first choice for a small SaaS. But what if some users want to pay with USDT or USDC? Would you add a simple crypto payment link or just stick with cards? Curious how other indie devs handle this.

NodeX — Fri, 16 Oct 2026 08:13:32 +0000

Stripe, PayPal, or Crypto? Choosing Payments for a Small SaaS

NodeX — Fri, 16 Oct 2026 08:12:40 +0000

You've built your SaaS. The frontend works, authentication is sorted, and your app is finally ready for users.

Now comes the less exciting part: getting paid.

For most indie developers, the first two options are pretty obvious: Stripe and PayPal. They're well-known, customers trust them, and you can find plenty of tutorials for integrating both.

So why would anyone bother looking at crypto payments?

Stripe and PayPal are probably where you should start

If Stripe is available in your country, supports your business, and your customers are happy paying by card, there's usually no reason to complicate things.

Stripe has good developer documentation, subscription billing tools, and a checkout flow that most customers already understand.

PayPal is another reasonable option, especially when customers prefer paying through an account they already use.

But things aren't always that straightforward.

Maybe Stripe doesn't support your business location. Maybe your customers are spread across countries where international card payments aren't particularly convenient. Or maybe you run a digital service and keep getting requests for a payment method other than cards or PayPal.

These aren't problems every developer will encounter, but they're common enough to be worth thinking about.

Where stablecoin payments fit in

This is where USDT and USDC can become useful.

I'm not suggesting that crypto should replace Stripe or PayPal. For most SaaS products, cards are probably still the easiest way for customers to pay.

But if you're selling developer tools, API credits, hosting, or other digital services to an international audience, you might already have customers who hold stablecoins and would prefer spending them directly.

Instead of asking those users to go through another payment method, you can offer USDT or USDC as an additional checkout option.

The interesting question then becomes: how much payment infrastructure do you actually want to build?

You don't need to build a crypto payment system from scratch

The simplest option is putting a wallet address on your website.

That technically works, but it isn't a great checkout experience. You'll need to figure out who sent each payment, whether the amount is correct, which network was used, and when to deliver the product.

For a couple of manual orders, fine. For a SaaS with automated account upgrades or credit purchases, not so much.

A hosted payment link is a better starting point for a small project. You create a payment request, send the customer to a checkout page, and let a payment provider handle supported network options and transaction tracking.

If your app needs automated fulfillment, you'll eventually want an API and webhooks.

For example, imagine selling $10 worth of API credits:

A user selects the $10 package.

Your backend creates an order.

The user is redirected to a hosted checkout.

The payment provider detects and confirms the payment.

Your backend receives and validates a webhook.

Your system marks the order as paid and adds the credits.

The important part is not trusting the checkout redirect alone. You need to verify the payment status server-side and make sure processing the same webhook twice doesn't credit the user twice.

You'll also need to think about underpayments, expired orders, refunds, and payments sent on the wrong network.

Not exactly glamorous work, but neither is debugging a customer's missing credits at 2 AM.

Would I self-host or use a payment provider?

It depends on what you're building.

If payment infrastructure is a core part of your product, self-hosting and monitoring blockchain transactions directly may be worth the effort.

If you're working on a small SaaS, though, I'd rather spend that time building features people actually want.

There are hosted services that handle the checkout and payment notifications for you. One example is JangoPay, which I work on. It offers stablecoin payment links and API/webhook integration for online merchants.

Regardless of the provider, I'd compare documentation, supported networks, fees, settlement, refund handling, and what happens when a payment goes wrong.

And of course, accepting crypto doesn't remove your responsibility to follow payment regulations or your provider's business restrictions.

My takeaway

I'd still start with Stripe or PayPal for most indie projects. They're familiar, widely used, and good enough for a lot of businesses.

But if customers are asking for alternative payment methods, stablecoins are worth considering as an additional option.

Start with the payment method your customers actually want. Add the complexity only when there's a reason to.

For those running a small SaaS or developer tool, are you sticking with Stripe/PayPal, or have customers started asking you for crypto payments?

How to Accept USDT Payments on Your Website: A Developer's Guide

NodeX — Fri, 16 Oct 2026 07:49:29 +0000

Say you're running a SaaS product and someone wants to pay $19 for a monthly plan. They already have USDT in their wallet, and they're happy to use it. You could give them a wallet address, wait for the transfer, and activate their account manually.

That sounds fine until you start getting more than a handful of payments. Now you need to figure out which transfer belongs to which customer, whether the amount is correct, and whether the same order has already been processed.

The blockchain transaction isn't usually the hard part. It's everything your application needs to do around that transaction.

Let's look at the options for accepting USDT on a website, what a basic integration looks like, and a few payment-handling details that are easy to get wrong.

Three ways to accept USDT

The simplest approach is direct wallet payments. Put a USDT address on your checkout page, ask customers to transfer funds, and verify the transactions yourself. There's very little setup involved, which makes it reasonable for occasional payments or small private transactions.

The trouble starts when several customers send similar amounts, someone chooses the wrong network, or a payment arrives after the order expires. You need a reliable way to identify the payer, monitor confirmations, handle exceptions, and update orders. A static wallet address doesn't do that for you.

The second option is building your own payment infrastructure. You can generate payment addresses, monitor supported blockchains, match transactions against orders, and maintain the necessary reconciliation logic. This gives you considerable control, but it also means maintaining RPC connections, blockchain monitoring, security controls, and recovery procedures.

The third option is using a payment gateway. Your website creates a payment order, the gateway provides the payment details, and your backend receives the payment result. You still control your products, customers, and fulfillment logic, but you don't have to implement every part of blockchain payment processing yourself.

For most small SaaS teams, I'd start by evaluating the third option before committing engineering time to a custom payment system.

Start with your own order, not the wallet address

Here's a small detail that matters more than it first appears: your application should create its own order before asking the customer to pay.

Imagine someone purchases a $19 subscription. Your database should know who placed the order, what they're buying, how much is due, and whether the order has been paid. The payment provider's transaction is associated with that order, not treated as the order itself.

A minimal database table might look like this:

CREATE TABLE payment_orders (
order_id TEXT PRIMARY KEY,
provider_invoice_id TEXT UNIQUE,
amount_usd NUMERIC(18, 2) NOT NULL,
status TEXT NOT NULL DEFAULT 'pending',
created_at TIMESTAMPTZ DEFAULT NOW()
);

It's deliberately boring. You can add customer IDs, payment asset details, expiration times, transaction identifiers, and reconciliation fields later. The important thing is that your application has a stable order reference and doesn't depend on the customer's wallet address to identify a purchase.

Also, calculate the price on your server. Don't trust an amount sent directly from the browser. If someone edits the request from $19 to $0.19, your backend should still know the actual price of the subscription.

Adding USDT checkout with JangoPay

For this example, I'll use JangoPay, a stablecoin payment platform built for online businesses. It provides Payment Links for simpler collections and APIs for applications that need to connect payments with their existing order systems.

The basic workflow is familiar if you've integrated a traditional payment gateway before: create a local order, create a payment invoice, collect payment, and update your application after confirmation.

JangoPay's developer documentation includes a Node.js SDK. Its documented methods allow a backend to create an invoice and request payment details for a supported asset and network.

Here's a simplified TypeScript example using those SDK methods:

import { JangoPayClient } from "jangopay-node-sdk";

const client = new JangoPayClient({
apiKey: process.env.JANGOPAY_API_KEY!
});

const { invoice } = await client.createInvoice({
orderId: "ORDER-1042",
amount: "19.00",
currencyCode: "USD",
allowedCurrency: ["USDT"]
});

const payment = await client.confirmPaymentCoin(
invoice.invoiceId,
"USDT",
"tron"
);

This illustrates the documented SDK calls, not a complete production checkout. Before creating the invoice, your application should load the actual order from its database and query the currently available payment assets. The selected currency and network must be supported for your merchant account.

The payment result contains the receiving information needed for that payment session, including the payment address and payable amount. Your frontend can use those details in a checkout interface, while your API credentials remain on the server.

If you don't want to build a checkout UI, JangoPay also provides hosted Payment Links. That's often a better starting point for a small business that wants to validate customer demand before writing a full integration.

Official documentation: https://doc.jangopay.org/integration-guide

Don't use the success page to activate the product

This is probably the most important part of the integration.

A customer completes payment and returns to your website. The browser displays a success message, so your application activates their subscription.

That implementation looks convenient, but it's not reliable. The customer might close the browser before returning, a payment might still be confirming, or someone might access the success URL without actually paying.

The frontend redirect is part of the user experience. It is not proof of payment.

Your backend needs a verified payment result before it changes the customer's account. Payment providers commonly handle this through Webhooks, and JangoPay supports server-to-server payment completion notifications.

One implementation detail is worth checking carefully: JangoPay's current documentation describes encrypted Webhook payloads using RSA-OAEP-SHA256 and AES-256-GCM. That is different from copying a generic HMAC signature verification example from a Stripe tutorial.

Your receiving service must decrypt the notification according to the documented envelope format. Encryption and successful decryption alone should not be treated as proof that the request came from the payment provider; the application should also establish the event's authenticity, including checking the authoritative invoice status through the authenticated API when necessary.

After verification, your application should match the invoice to an existing local order, check the expected amount and status, and only then perform fulfillment.

There is another problem to handle: duplicate notifications.

Webhooks can be delivered more than once. If your code adds $19 in credits every time it receives the same completion event, a single payment can turn into multiple balance updates.

The fix belongs in your database, not just in an application-level if statement. A successful order transition and the corresponding credit or fulfillment record should happen atomically, with a unique reference that prevents the same purchase from being processed twice.

JangoPay's current Webhook documentation does not specify a separate event ID in its completion payload. It recommends deduplicating using the event type together with the relevant invoice or transaction identifiers.

That sounds like a small implementation detail, but it's the sort of thing you want to discover before customers start paying real money.

What I'd test before going live

A successful test payment is only the beginning. I'd also check what happens when a customer underpays, selects an unsupported network, pays just before expiration, or sends funds after the payment window has closed.

Then I'd deliberately send the same completion notification multiple times and confirm that the application activates the subscription only once. I'd test what happens when the Webhook endpoint is temporarily unavailable, and whether the backend can reconcile an order by querying its status later.

Finally, I'd verify that no API keys, private keys, or sensitive payment information have ended up in frontend code, public repositories, or application logs.

These tests aren't particularly exciting, but payment bugs have a habit of becoming support tickets, accounting problems, and unhappy customers.

Do you actually need a payment gateway?

Not necessarily.

If you receive two USDT payments a week and are happy verifying them manually, adding a payment gateway might not save you much time. If you're building a product with recurring customer purchases, account top-ups, automated delivery, or international customers, the calculation changes.

That's where services like JangoPay become useful. Rather than spending your time maintaining blockchain payment infrastructure, you can focus on the application logic your customers actually care about.

USDT and USDC don't have to replace cards or other payment methods, either. They can simply provide another checkout option for customers who already prefer using stablecoins.

The main thing I'd keep in mind is this: a transaction arriving in a wallet is not the same as a payment being completed in your application. Once you design around that distinction, the rest of the integration becomes much easier to reason about.

If you're building something similar, I'm curious: are you handling crypto payments with your own wallet monitoring, or using a gateway?

Developer resources

JangoPay website: https://jangopay.org

Integration guide: https://doc.jangopay.org/integration-guide

API reference: https://doc.jangopay.org/api-reference

Note: The SDK excerpt illustrates methods from the public documentation and has not been independently tested against a live merchant account. Verify the installed SDK version and current API contracts before production use. JangoPay availability is subject to merchant eligibility and applicable regional restrictions.