A payment link can collect an event fee without building a checkout integration. Share it beside your event information or display its QR at check-in. Attendees pay in USDC, and your team checks the result against its own registration list.
PayIn handles the payment request and records. It does not automatically sell tickets, reserve seats, identify attendees or issue admission passes. Those steps remain part of your event process unless you build and verify an integration.
Decide who the event is suitable for
USDC collection is most practical when attendees already have a compatible wallet and USDC on a network you accept. Do not advertise wallet payment as equivalent to paying by card. If many attendees are new to crypto, provide clear instructions and an alternative method in your own booking process.
PayIn currently supports Base, Polygon and Solana. Prepare your receiving wallet and the Solana USDC token account if that network is enabled. The receiving setup guide covers the requirements.
Make the fee and admission terms explicit
Suppose a workshop costs 25 USDC. Use a fixed-amount request titled “Saturday ceramics workshop.” This is an example, not a real event or payment offer.
Place the date, venue, cancellation policy, capacity and what counts as a confirmed booking on your event page. The short payment title helps recognition; it is not a substitute for the event description or terms. Explain whether payment reserves a place immediately or whether your team confirms the booking afterward.
Do not rely on a reusable link to stop selling automatically when a venue is full. Track capacity in your booking system and pause collection when needed. A submitted payment still requires reconciliation even if you pause new payments.
Create and distribute the payment link
Follow the free payment link tutorial, save the private management link, and copy the public Payment link from Links. Add that public URL as the payment button on your event page or send it in a registration email.
Creation and use currently require no PayIn registration or subscription. The organizer supplies the receiving address; the attendee approves payment in their own wallet. Never publish the management link or put it in a QR for attendees.
Match a payment to an attendee
For a small event, keep a registration list with attendee contact, expected amount, payment status and transaction reference. Ask the attendee for the reference when you cannot match the payment confidently.
Two attendees can pay the same amount through one shared link. The amount alone does not identify them. Avoid collecting unnecessary personal information on a public payment title or treating an unverified screenshot as a ticket.
| Record | Why it helps |
|---|---|
| Your registration reference | Identifies the booking in your own system |
| Expected amount and network | Makes payment checks consistent |
| Confirmed transaction reference | Connects the payment to your review |
| Admission status | Separates successful payment from check-in |
These are suggested fields for your event records, not a claim that PayIn generates a ticketing database.
Set up a QR at check-in
For on-site payment, open the POS display on a tablet facing attendees and enable sound on that device. The display and announcement languages can be set separately. Keep the connection indicator visible and the browser active.
After a newly confirmed payment, the POS can show success and announce the amount. Check the correct fee and update the attendee's admission status yourself. For uncertain cases, consult management rather than relying on a sound heard earlier.
The QR guide explains printing and scanning checks; the POS guide covers device setup.
Reconcile cancellations and unclear payments
An Awaiting payment record is an attempt, not a booking confirmation. Unsubmitted attempts expire after 15 minutes. Transactions already submitted for confirmation continue to be checked. Do not ask an attendee to pay again until an unclear submitted transaction has been reconciled.
If you agree to a refund, verify the recipient and arrange a separate transfer. The refund does not automatically cancel an admission record or return a seat to inventory; update your event system as well.
For larger events, use a verified payment-to-registration integration and make fulfillment idempotent. Developer work is required; it is not enabled simply by creating a link.