#Choosing an integration

There are several ways to accept card payments through PlutoPay, trading integration effort for control over the customer experience. Pick the one that matches how much you want to build.

#The ladder

Method	Effort	Who hosts the card form	Best for
Payment links	Zero code	PlutoPay	Invoices, one-off charges, no website needed
Hosted checkout	Low code	PlutoPay	Redirect from your site to a prebuilt payment page
Elements (custom)	Full control	Your page (Stripe.js tokenizes)	Keeping customers on your own branded checkout

All three keep card data off your servers — the card is entered into a Stripe-hosted field or the PlutoPay-hosted page, so your PCI scope stays minimal (SAQ A). Every method applies the same 3% platform fee and reconciles identically.

Payment links →

Create a shareable URL. No website required.

Hosted checkout →

Create a session, redirect, get a webhook on completion.

Elements (custom) →

Create a payment, mount the Payment Element on your page.

#Which should I use?

No website, or you just need to get paid → Payment links. Create one, share the URL, done.
You have a site and want the simplest redirect → Hosted checkout. Create a session, send the customer to the returned url, fulfill on the payment.succeeded webhook.
You want customers to stay on your own branded page → Elements. Create a payment to get a client_secret, then mount Stripe.js’ Payment Element on your checkout page. Stripe.js tokenizes the card client-side; your server never sees card data.

#Other payment methods

Beyond cards, the same transaction API accepts:

ACH bank debit — payment_method_type: ach, verified up front via Financial Connections. Cheaper, asynchronous.
Terminal — card-present payments on a physical reader.

Whichever you choose, completion is confirmed by webhook and every amount is in cents.