Payments

The Payments tab is the record of every payment your organization has taken - manual payments logged by staff, card payments captured by a provider, and wallet credit applied at checkout. Use it to see what has been collected, which method was used, who recorded it, and to issue refunds. A payment settles one or more transactions; the payment carries an amount, a method, a status, and a link to the transactions it paid.

​

Overview

Use Revenue > Payments to review payments, filter by status, and drill into a single payment. Payments are created when a member pays online, when a scheduled bill run charges a card, or when a staff member records a manual payment at the front desk.

• Payment list - Every payment with its status, method, amount, and the admin who recorded it.
• Payment details - Open a payment to see amount, method, status, the linked transactions, the Created by admin, and any provider references (for example a Stripe payment intent).
• Record payments - Log a manual payment (cash, card terminal, bank transfer) against a transaction or invoice.
• Partial and split payments - Take part of a balance now, split a charge across a primary method and wallet credit, or give each player on a booking their own share.
• Refunds - Return money to the card, the member’s wallet, or by hand. Issued from the transaction, in full or in part.

​

The payment list

Open Revenue > Payments. The grid shows these columns:

• Date - When the payment was recorded.
• Contact - The member the payment is for.
• Amount - The payment amount and currency.
• Payment method - The method used (for example Cash, Card, or a card provider).
• Status - Succeeded, pending, failed, refunded, partially refunded, cancelled, or processing.
• Created by - The admin who recorded the payment.

Tabs across the top filter by status: All, Succeeded, Pending, and Failed, each with a count. Click a row to open the payment. Where you have the right permission, the row action menu offers Delete for eligible payments (see Deleting a payment). The Created by column shows the admin who recorded the payment. For payments captured automatically by a provider (online checkout, scheduled bill runs), the column is empty - those are system-recorded. For manually recorded payments (front desk, phone, bank transfer logged by staff), it shows the admin’s name.

​

Payment status

A payment moves through these states:

• Pending - Recorded but not yet settled (for example a manual payment awaiting confirmation, or an online payment mid-flow).
• Processing - The provider is capturing the payment.
• Succeeded - The money is in. This is the only state a payment can be refunded from.
• Failed - The attempt did not go through.
• Cancelled - The payment was called off before it settled.
• Refunded - The full amount has been refunded.
• Partially refunded - Part of the amount has been refunded.

​

Recording a payment

Most manual payments are recorded as part of a flow rather than from a blank form - completing an order, settling an invoice, or taking money at the point of sale all record a payment behind the scenes. When you record one, 1Club needs:

• Amount - How much is being paid.
• Payment method - Which configured method the money came in on (see Payment methods).
• What it settles - A transaction, several transactions, or an invoice.

For example, completing a draft order opens the Complete order dialog, where you pick a payment method; 1Club then records a payment against each of the order’s unpaid transactions with that method. See Orders.

​

Payment methods used

Each payment records the method it came in on. Methods belong to a channel:

• Manual - Methods you take and log yourself, such as cash, an in-person card terminal, or a bank transfer. You define these under Payment methods.
• Card provider - Online card payments captured through the connected provider’s checkout.
• myPOS - Payments taken through a myPOS terminal or link. See myPOS.
• Wallet - The member’s stored wallet balance, applied as credit (see Wallet).

The method shown on a payment tells you where the money physically came from, which matters when you reconcile the till or a bank statement.

​

Partial and split payments

You do not have to settle a balance in one payment.

• Partial payment (one transaction) - Record less than the full amount against a single transaction. The transaction moves to partially paid and keeps an outstanding balance you can collect later.
• Settling several transactions at once - You can record one payment against multiple transactions, but only when the payment covers all of them in full. A single lump sum cannot be split partially across several transactions, so a multi-transaction payment must equal the sum of their outstanding balances.
• Dividing a booking between its players - Give each player on a booking their own share and their own way of paying it. See Splitting a booking across its players.

​

Splitting a booking across its players

Four people book a padel court and each want to pay their own quarter. Rather than one person paying and chasing the others, split the bill so each player owns their own charge. On the booking’s detail page, use Split payment (or Edit split if one already exists). The dialog explains:

Divide between the players. Each one can pay their own way. Shares are shown before tax.

For each player you set:

• Share - their slice of the price, before tax.
• Pays with - how they are covering it: paying directly, a membership, or an external program. Until they choose, the row reads Not chosen yet.

A player covered by a membership or program shows as Covered and is charged nothing - their entitlement is used instead, exactly as it would be on a booking of their own.

​

Even and custom splits

• An even split divides the price equally and re-divides it whenever the roster changes. Add a fifth player and all five shares rebalance, rather than leaving a gap.
• A custom split takes the amounts you enter. Because the shares are the price in that case, changing them reprices the booking, and 1Club tells you so before you save: “This changes the booking price from to .” That is intended - charging the four players more or less than the court’s list rate is a legitimate thing to do at the desk.

Two rules are enforced on save: no share may be negative, and everyone holding a share needs a payment method.

​

Collecting each share

Each player’s share becomes their own charge, so you collect them independently from the players list on the booking, or from Transactions like any other charge. A player who has settled is marked as such even while others still owe. This also drives entry: the check-in gate asks whether this player has paid their own share, so three players who have paid are admitted while the fourth is still outstanding.

​

Re-splitting after money has changed hands

You can edit a split after players have paid. Anything already collected is returned as wallet credit, not discarded:

Anything already paid goes back to that player’s wallet, so they can settle their new share from it.

Memberships and program entries consumed by the old split are given back before the new one is applied, so re-splitting twice never quietly drains a member’s allowance.

​

Splitting across a method and wallet credit

You can combine a primary method with wallet credit in one checkout:

• Member portal - Wallet credit is applied automatically. The order deducts the wallet balance (up to the amount due) and the member pays only the remainder by card or on arrival. The breakdown shows a Wallet line (for example Wallet: -10.00) above the total, and the Pay button reflects the post-wallet amount.
• Admin point of sale - When you take a payment with a primary method (card, cash, and so on), you can also apply wallet credit as a secondary payment via the Also apply wallet credit ( available) checkbox and an Amount from wallet field. The split is shown as “Wallet + via primary method”. The wallet toggle is hidden when the wallet already covers the full amount (you can then pay entirely from the wallet).

The amount drawn from a wallet is always capped at the member’s balance and the outstanding amount.

​

Refunds

Refunds are issued from the transaction, not from the payment, and you choose where the money goes. Open the charge in Transactions and use Refund.

​

Issuing a refund

1. Open the transaction from Revenue > Transactions.
2. Click Refund. The Refund transaction dialog opens.
3. Answer Where should the money go? (see the destinations below). Each option shows its own ceiling, because they differ.
4. Set Amount to refund. It defaults to everything still refundable, and cannot exceed the ceiling for the destination you picked.
5. Optionally add a Reason.
6. Click Issue refund.

Refunds require the billing manage permission at the organization level.

​

Choosing a destination

Only options the original payment supports are offered. Back to the card appears only for payments taken through Stripe: money collected through myPOS, DatecsPay, or Hype cannot be reversed through those providers from 1Club yet, so return it as Wallet credit or by hand at the till. The ceilings differ per destination because they are calculated per payment. A transaction settled partly by card and partly from the wallet can return only the card portion to the card.

​

Card refunds are not instant

When you refund to the card, 1Club tells you:

The refund is sent to Stripe now and usually reaches the member’s statement within 5-10 days. It is drawn from your Stripe balance.

Some card refunds settle asynchronously, so you may see a refund reported as awaiting confirmation:

Refund sent to Stripe - awaiting confirmation. It is not back with the member yet.

That is a normal intermediate state, not a failure. The amount is confirmed once the provider settles it, and the transaction’s status updates then. A partial confirmation reads as “X refunded, Y sent to Stripe and awaiting confirmation” - treat only the confirmed part as money the member has back.

​

Partial refunds

Enter any amount up to the ceiling. Each refund is recorded individually with its amount, destination, reason, and who issued it, so a charge refunded in three instalments has three records rather than one status flag. You can keep refunding until the refundable balance is exhausted.

​

Nothing to refund

If no money was ever collected on the transaction, Refund tells you so:

Nothing was collected on this transaction, so there is nothing to refund. Void it instead if it should never have been charged.

See Voiding a transaction for that path.

​

Automatic wallet-credit refunds

Some flows refund a member automatically by crediting their wallet rather than reversing the original tender, without asking you to pick a destination:

• A booking is cancelled under a cancellation policy. The refund follows the tiered rules on the matching policy - see Booking policies.
• An order is cancelled.
• A member’s entrance method changes at check-in (they paid directly, then a membership or program is used to admit them instead). 1Club marks the original payment refunded and credits the amount to their wallet.
• A booking’s split is edited. Anything already paid goes back to each player’s wallet so they can settle their new share from it - see Splitting a booking across its players.

​

Payment links

When you send a member a link to pay an outstanding amount, the link opens a branded payment launcher on your organization’s member-facing site. The launcher shows your organization’s logo and theme colours, the amount due, the reference, and the date, with a Continue to payment button that hands off to the payment provider (myPOS) to complete the payment. The launcher resolves to your member-facing site automatically - it uses your verified custom domain, then your published website, then the member portal, then the network, so members land on a branded page rather than a generic one. The launcher also reflects the link’s state, for example:

• “This payment link has expired”
• “This payment has already been completed”
• “Thank you, your payment was received”
• “Payment cancelled”

​

Deleting a payment

Only manually recorded payments can be deleted. That means every method on the manual channel - Cash, an in-person card terminal, a bank transfer, or whatever else you have defined. Those rows are just a record of money taken at the counter, so removing the record is the whole correction. Everything else must be refunded instead, because the money sits somewhere a deleted row cannot reach:

• Card provider, myPOS, DatecsPay, Hype - the provider is holding the funds.
• Wallet - the member’s wallet was debited.

Attempting it tells you:

Only manually recorded payments can be deleted. This one was collected through a payment provider or the wallet, so refund it instead.

A manual payment may settle several transactions at once - a multi-line invoice, a booking split across a court and an instructor, a point-of-sale order. Deleting it recalculates every affected transaction back to paid, partially paid, or pending based on what remains, so you do not have to unpick them yourself. Deletion requires the billing delete permission at the organization level.

​

Worked examples

​

Padel court paid half now, half on arrival

A member books a court and pays half at the desk, settling the rest when they arrive.

• Record a partial payment for half against the booking transaction; it moves to partially paid.
• On arrival, record a second payment for the remainder to bring it to paid.

​

Boxing gym monthly fee split across card and wallet

A member has 10.00 of wallet credit and owes 40.00 for the month.

• At the point of sale, take the primary method (card) and tick Also apply wallet credit (10.00 available).
• The split shows “Wallet 10.00 + 30.00 via primary method”; the card is charged 30.00.

​

Cancelled climbing session refunded to wallet

A climber cancels a booked session within the free-cancellation window.

• The booking is cancelled and, under the cancellation policy, the amount is credited to the climber’s wallet automatically.
• The original payment is reflected as refunded; the wallet balance is available for their next visit.

​

Front-desk cash payment recorded in error

Staff logged a cash payment against the wrong member.

• Cash is a manual method, so delete the payment. Every transaction it touched recalculates automatically, even if it settled several at once.
• Record the payment again against the right member.
• Had it been a card payment, deletion would be refused - refund it and re-take it instead.

​

Padel four-ball, each player paying their own quarter

Four members book a court for 60.00 and each wants to pay separately.

• On the booking, click Split payment. An even split gives each player 15.00.
• One player is on a membership: set their Pays with to that membership. They show as Covered and are charged nothing, and the other three still owe 15.00 each.
• Collect each share from the players list as they pay. The two who have paid can check in while the third is still outstanding.

​

Cancelled tournament entry returned to the card

A member paid 40.00 by card for a tournament that you then cancel outright.

• Open the entry charge in Revenue > Transactions and click Refund.
• Choose Back to the card, leave the amount at the full 40.00, and add a reason.
• The refund is sent to Stripe and may read as awaiting confirmation for a few days. Tell the member it typically lands on their statement within 5-10 days.
• Had you wanted to keep the money with the gym, Wallet credit would have returned it instantly as credit instead.

​

Tips & best practices

• Refund, do not delete, anything a provider or the wallet touched. Only manual-channel payments can be deleted. Refund the rest so the money actually goes back and the audit trail stays intact.
• Pick the refund destination deliberately. Wallet credit is instant and keeps the money with you; Back to the card is the right answer when the member is not coming back. Do not use wallet credit to avoid a card refund the member asked for.
• Read Created by to tell manual from automatic. A blank Created by means the provider captured it; a name means a staff member logged it. This is your first check when reconciling the till.
• Match the method to the money. Record the payment on the method it actually came in on (cash, terminal, transfer) so your Payments tab reconciles against your bank and till.
• Use partial payments for deposits. Take a deposit as a partial payment and collect the balance later rather than forcing payment in full up front.
• Split the bill rather than nominating a payer. On a group booking, give each player their own share so each is collected and admitted independently.
• Send a payment link for outstanding balances. Rather than chasing a member for card details, send the branded payment link and let them pay on your own site.

​

Troubleshooting

Issue: I cannot find a Refund action on the payment. Solution: Refunds are issued from the transaction, not the payment. Open the charge in Revenue > Transactions and use Refund there. You also need the billing manage permission at the organization level. Issue: Back to the card is not offered as a destination. Solution: The payment was not taken through Stripe. Money collected through myPOS, DatecsPay, or Hype cannot be reversed through those providers from 1Club yet - return it as Wallet credit, or hand it back at the till and record it as Cash. Issue: A refund says it is awaiting confirmation and the member says they have not received it. Solution: That is expected. Card refunds can settle asynchronously and typically reach the statement in 5-10 days. The amount is not back with the member until it is confirmed. Do not issue a second refund for the same money. Issue: Refund says there is nothing to refund. Solution: No money was ever collected on that transaction. If it should never have been charged, void it instead - see Transactions. Issue: The Delete action is refused on a payment. Solution: Only manually recorded payments (the manual channel: cash, terminal, bank transfer) can be deleted. Provider-collected and wallet payments must be refunded. A manual payment carrying a provider reference is also refused. Issue: A multi-transaction payment is rejected. Solution: A single payment can settle several transactions only when it covers them all in full. Record separate payments, or record a partial payment against each transaction individually. Issue: The wallet toggle is missing at the point of sale. Solution: The wallet already covers the full amount due, so the secondary-tender toggle is hidden - you can pay entirely from the wallet. It reappears when the wallet only partly covers the balance. Issue: One player on a split booking cannot check in although the booking is paid. Solution: Entry is judged per player, not per booking. Check that player’s own share on the booking’s players list - the others having paid does not settle theirs.

​

Related

• Orders - Complete an order to record payment against its transactions.
• Transactions - The charges a payment settles.
• Invoices - Invoices generate payments when paid.
• Payment methods - Configure which payment methods your organization accepts.
• myPOS - The provider behind payment links and terminal payments.
• Booking policies - Decide when payment is collected, and the tiered rules for cancellation refunds.