Appearance
Payments
The Payments area lists payments received through the platform for memberships, classes, and events. You can filter by type, date, or status, open a payment to see full details and how it links to a membership or enrollment, and identify failed or pending payments. Used by: Admin and Super Admin.
Routes: https://admin.uibeta.org/admin/payments (list), https://admin.uibeta.org/admin/payments/[id] (payment detail).
What the payments list shows
- Go to Payments in the sidebar (or https://admin.uibeta.org/admin/payments).
- The list shows payments with details such as amount, date, member (or customer), type (membership, class, event), and status. The Method column shows how the money arrived — Card, Check, Cash, or Waived — with the check number underneath when one was recorded. Click any row (or View) to open the payment detail page. Card payments that can be refunded also show a Refund button in the Actions column (see Refunds).
- To find a specific payment, use the Search box at the top of the filter panel and press Enter (or click Search). It matches either:
- Who paid — full name (
Jane Doe), partial name, or any part of the email address. - How much — the payment amount, entered as
125,125.00, or$125.
- Who paid — full name (
- Use filters to narrow the list further, for example:
- Type — Cart, membership, enrollment, event, registration, or donation. Most online checkouts are recorded as Cart (one payment covering everything in the basket), so start there if a payment you expect is missing from a narrower type.
- Date range — Payments in a given period.
- Status — Pending, Succeeded, Failed, Refunded, Partially Refunded, Reversed (never collected) (check or cash payments that were marked received by mistake — see Offline Payments), and Cancelled.
- Search and the filters combine, so you can search an amount and still limit the results to a single date range or status.
The New payment button at the top right opens Record offline membership, for logging a cash, check, or comp membership. See Offline Payments.
Abandoned card checkouts are hidden and cleared automatically
When a member starts a card checkout and walks away, a pending payment is left behind. These are hidden from the default All Statuses view so they don't clutter the list, and after 24 hours the system moves them to Cancelled on its own. This includes checkouts where the member got as far as the card form; those are also cancelled in Stripe, but only when no money was taken. If the checkout used a coupon with a usage limit, that use is given back when it is cancelled. Nothing was ever charged on them, so no refund or email goes out. To see them, pick Pending or Cancelled from the Status filter.
This page is for payments tied to memberships, classes, and events. Donation products and recurring gifts are managed under Giving — see Donation Products and Recurring Donors. Donation charges still show up in this Payments list when you filter Type = donation.
Exporting the payments you are looking at
Click Export CSV at the top right of the payments list to download the payments currently selected by your filters. When any filter is active the button reads Export filtered CSV, so it is clear the file matches the screen. Every filter — search, type, status and date range — is applied to the download.
The file contains one row per payment with these columns:
| Column | Meaning |
|---|---|
| Created At (UTC) | When the payment record was created (checkout started, or the offline order was recorded). |
| Paid At (UTC) | When the payment actually completed. Blank on older records that were never stamped, and on payments that have not been paid. |
| Payer / Email | The member the payment belongs to. Blank for guest checkouts with no account. |
| Type, Status | Same values as the on-screen filters. |
| Needs Attention | Yes when the card was charged but part of the order could not be set up (see Payments that need attention). Blank otherwise — including ordinary check and cash orders still waiting for payment, which need a different action. |
| Gateway | stripe, cash, check, or waived. |
| Check Number | The check number recorded when a staff-entered order was confirmed as paid by check. |
| Subtotal | Products after discounts and coupons, before the processing fee. Blank on pre-2026 records, where the split was not stored. |
| Processing Fee | The Stripe fee passed through to the payer. 0.00 for cash and check. Blank means unknown, not zero. |
| Amount Charged | The total actually charged. |
| Gross (Revenue Basis) | Subtotal when it is known, otherwise Amount Charged — the same figure the revenue report counts as gross, so the two can be compared. A reversed payment shows 0.00 here (and in Net), because the money was never collected. |
| Refunded | Total refunded against this payment, from the same source the revenue report uses. |
| Net (Gross − Fees − Refunds) | Gross minus the processing fee minus refunds. |
| Refund Reason | Why the payment was refunded, using the reasons from the refund form. If a payment was refunded more than once for different reasons, they are listed together, separated by ;. Blank when there was no refund. |
| Stripe Payment Intent / Stripe Session | Identifiers for looking the charge up in Stripe. |
| LGL Gift ID | The gift(s) created in Little Green Light, if the payment has synced. |
| Payment ID | The internal payment record ID. |
| Items | What the payment was for: the item names in the order they were bought, separated by ;, with x2, x3 and so on when more than one was bought (for example Elementary Spanish; Gala Ticket x2). Blank when the payment has no itemized lines. Added as the last column so existing column positions did not move. |
Which date the export uses. The on-screen list filters by the created date. The export's date range filters by the paid date, falling back to the created date when a payment has never been stamped as paid — the same rule the revenue report uses. This is deliberate: it means a month's export and that month's revenue summary agree on which payments belong to the month. A payment created on 30 June and paid on 1 July therefore appears in a July export but on the June screen; both dates are columns in the file so you can always see which rows are affected.
The file is saved so that accented names (for example José or Müller) display correctly when opened in Excel or Numbers.
A single export is capped at 50,000 rows. If your filters match more than that, the file ends with a row reading TRUNCATED AT 50000 ROWS — narrow your filters, so a truncated file is never mistaken for a complete one.
What the payment detail page shows
When you open a payment (https://admin.uibeta.org/admin/payments/[id]), you see:
- Amount — What was charged (and currency).
- Payment method — Card, Check, or Cash in office, plus the Check number and any Notes staff recorded (for example the reason a fee was waived).
- Paid — When the payment was completed. For a cash or check payment this is the day staff entered as the date received, shown as a date only (no time of day). Card payments show the date and time.
- Line items — Breakdown of what was purchased (e.g. membership, class, event line). Class lines also show the instructor, meeting days, and semester underneath the class name, so two classes with the same name can be told apart. If a coupon was used, its code is shown too.
- Date and time — When the payment was made.
- Status — Succeeded, pending, failed, refunded, partially refunded, reversed, or cancelled.
- Refunds — Shown when the payment has been refunded, in full or in part. Each refund lists the amount, date, reason, any notes, whether the processing fee was kept (Fee withheld) or returned (Full amount), who issued it, and the Stripe refund ID. Underneath are the Total refunded and the Net kept.
- Stripe reference — Link or ID to the payment in Stripe (for finance or support).
- Linked membership or enrollment — The membership or class/event enrollment this payment is tied to. Use this to jump to that record (e.g. to extend a membership or view an enrollment).
- LGL sync jobs — Information about Little Green Light sync tasks tied to this payment (so you can see whether the gift or payment was queued or sent to the CRM). The LGL chip shows Synced, Queued, Failed or Pending. If the sync failed, a red box says This gift did not reach LGL and gives the reason. Fix the cause (for example the fund mapping), then click Sync to LGL. Failed jobs are also listed on the sync queue page.
- Receipt — For gifts, the Receipt chip shows Not sent if the donor's tax receipt never went out, and a yellow Receipt not sent box appears. A Super Admin can click Resend receipt to email it. Clicking twice won't send two; if one already went out, the page says nothing new was emailed.
- Customer — The user or member who paid.
Use this page to confirm what was paid for, to follow up on a refund, to troubleshoot a member’s question, or to check CRM sync status.
If the payment is an offline order (paid by check or in office), this page is also where you confirm it, cancel it, push its deadline out, bring back one that expired, or reverse one that was marked paid by mistake. See Offline Payments. When you reverse a gift whose tax receipt was already emailed, the reverse window warns you with the amount and date, so you can let the donor know.
Finding a payment in Stripe
Card charges carry a description in Stripe like UIE-4F3A2B1C · Jane Smith · Beginner Spanish. The part after UIE- is the first eight characters of the Payment ID (the column just before Items in the payments CSV), and the member's name is included so you can search Stripe by name.
Identifying a failed or pending payment
Failed — The charge did not go through (e.g. card declined). The member does not have the product until they pay successfully. You may see a failed payment in the list; the member may need to update their payment method and try again on the site, or you may need to process their payment another way (e.g. manual/offline and then create membership or enrollment as appropriate).
Pending — Usually one of three things:
- A check or cash order waiting for the money to arrive. Handle it from Offline Payments.
- A card checkout the member never finished. These are hidden from the default view and cancelled automatically after 24 hours (see above) — no action needed.
- A card payment marked Needs attention — see below.
If a card payment stays pending for another reason, check with Andrew or your finance lead.
Filter the payments list by Status (failed or pending) to find these quickly.
Payments that need attention
Occasionally a member's card is charged but part of the order can't be set up automatically (for example, one class in the cart could not be enrolled). Rather than marking the payment as complete, the system keeps it pending and shows a yellow Needs attention badge under the status in the payments list — even in the default view. The same payments show Yes in the Needs Attention column of the CSV export.
The member is not sent a normal receipt. Instead they get an email titled "Your order is on hold while we finish it", which states the amount charged, marks each item as set up or still outstanding, and tells them the team is working on it.
What to do: open the payment, check the charge in Stripe, and finish setting up the outstanding items by hand (for example, add the missing enrollment). The system will not retry these on its own. These payments are never auto-cancelled with abandoned checkouts. Contact Andrew if you are unsure how to complete an item.
Reconcile with Stripe
Who can reconcile
The Reconcile with Stripe button is visible to any Admin who holds the Manage payments permission (admin:manage_payments) — the same permission as Issue Refund. Admins have it by default. Super Admins always see it.
Use Reconcile with Stripe on a payment detail page when Stripe has already captured the money but LGL, grant, receipt, or notify steps did not finish. It looks up this payment in Stripe only. It does not create a charge.
- Open the payment detail page (https://admin.uibeta.org/admin/payments/[id]).
- In the Stripe & LGL card, click Reconcile with Stripe. There is no confirmation dialog — the action is retrieve-only.
- Wait for the result banner. Unfinished fulfillment may resume; if Stripe is still processing or canceled, no charge is created.
If the banner says "Stripe confirms the charge, but this order was never fulfilled. It was left pending on purpose, so reconciling again won't change it.", the payment is one that needs attention. Clicking again gives the same answer. Finish the outstanding items by hand instead.
Hide cases: cash/check pending orders (use Confirm payment received), refunded/cancelled/failed payments, and succeeded payments that already finished every fulfillment step.
Refunds
Who can issue refunds
The Refund and Issue Refund buttons are visible to any Admin who holds the Manage payments permission (admin:manage_payments) — Admins have it by default — and to all Super Admins. If that permission has been revoked for a specific admin, they will not see the buttons.
Which payments can be refunded here
Only card payments with status Succeeded or Partially Refunded that have a matching charge in Stripe. The refund buttons are not shown for check, cash, or waived payments (there is no card charge to send money back to), or for a card payment with no Stripe charge behind it (for example a $0.00 order). If a check or cash payment was marked received but the money never arrived, reverse it instead — see Offline Payments.
How to issue a refund
Start from either place:
- the payments list — click Refund in the row's Actions column, or
- the payment detail page (https://admin.uibeta.org/admin/payments/[id]) — click Issue Refund.
Both open the same Confirm Refund window.
Items to Refund — tick the items you want to refund. The amount is worked out from your selection. Items priced $0.00 are marked (waived) and items already refunded are marked (refunded); neither can be ticked. An item refunded in part earlier is marked (partial). A payment with no itemized lines shows a single Full payment line.
Reason for Refund (required) — pick the closest match:
- Class or event cancelled
- Instructor change
- Schedule, time, or location change
- Member withdrew or cannot attend
- Membership cancelled
- Duplicate charge
- Price correction or overcharge
- Staff entry error
- Fraudulent charge
- Other (explain in notes)
The reason you pick is saved on the payment and appears in the refunds ledger and the payments CSV. Stripe only accepts three reasons of its own, so Stripe is sent the closest one (almost always "requested by customer"). Only use Fraudulent charge for genuine fraud — Stripe treats it as a risk signal on the account.
Notes (optional) — context for staff, up to 500 characters. If you chose Other, explain the reason here.
Processing fee — choose how to treat the fee the member paid on top:
- Full refund — the member gets back everything they paid for the selected items, including the processing fee. Use for duplicate charges or errors where no service was delivered.
- Fee-adjusted refund — the member gets back the product amount only; the processing fee is kept. The window shows exactly how much they will receive. Use when the service was partly or fully delivered.
- For older payments where fee data is not stored, the fee shown is an estimate and is labelled as one.
Override amount (optional) — to refund a specific dollar figure instead (for example a prorated refund), type it here. It can't be more than the total of the items you ticked. The amount you type is refunded exactly — the processing fee is not added or taken off.
Click the red Refund $… button, which shows the final amount. The Stripe refund is issued immediately, the payment status updates to Refunded or Partially Refunded, LGL gift records are updated for the refunded items, and the member is emailed a refund confirmation.
After a refund, the payment detail page shows it in the Refunds section with the amount, date, reason, and who issued it.
If you see "WAS issued, but recording it failed"
This means Stripe did send the money back, but the platform could not finish recording it. Do not try again — a second attempt could refund twice. Check the payment in Stripe and contact Andrew so the record can be corrected.
LGL sync failure after refund
If LGL sync fails after a successful Stripe refund, a warning appears: "Refund issued. LGL sync failed — check sync jobs." The Stripe refund stands regardless. Go to https://admin.uibeta.org/admin/sync, find the failed job, and retry. Contact Andrew if it fails repeatedly.
If you need to process a refund directly in Stripe (e.g. for a payment that isn't showing up here), do so in the Stripe dashboard. Enrollment or membership status in UIEngine will not update automatically in that case.
Refunds processed outside UIEngine (e.g. directly in Stripe) will not automatically update enrollment or membership status in the platform. Notify Andrew so records can be kept in sync.
Refunds ledger
To view a full history of all issued refunds (with the reason and the staff member who issued each one), filter by date, or export to CSV, use the dedicated Refunds report at https://admin.uibeta.org/admin/reports/refunds (sidebar: Reports & Sync → Refunds).
Need help? Contact Andrew.