Payments and wallets

#01How this page works

This page explains how payments, PayTo agreements, wallets, campus cards and meal plans work when an education Institution uses Academyship's payment features. It has two parts. They are written for different readers and have a different legal status.

Paying an Institution is not buying Academyship. Academyship sells its software to Institutions. A parent paying a school invoice, a student topping up a canteen wallet or an employer paying a course fee is paying the Institution. That payer is not buying Academyship's services and does not become a party to Academyship's Terms of Service by paying.

Nothing on this page excludes, restricts or modifies a right or remedy that cannot lawfully be excluded, including consumer guarantees under the Australian Consumer Law and a payer's rights under their banking or card terms.

#Part AInstitution module schedule

Part A is written for Institutions. It explains how the Payment Features work, who is responsible for what, and the rules that apply when an Institution uses them. "Academyship" means ACADEMYSHIP PTY LTD (ACN 698 283 448, ABN 89 698 283 448). "Institution" means the Customer under the Terms.

#A1When this schedule applies

A1.1 Applicability. This Part A is the Academyship Payments and Wallets Module Schedule, version 1.0 (the Schedule). It forms part of the agreement between Academyship and an Institution only when an Order Form, or a Module Activation, identifies the Schedule by name and version. It then applies only to the Payment Features covered by that Order Form or Module Activation, and only to their subject matter.

A1.2 Later versions. A later version of this Schedule does not apply to an Institution merely because Academyship publishes it. It applies only when an Order Form or Module Activation identifies it, or when it takes effect under the change process in section 31 of the Terms, including that section's advance notice of material changes and its protection against retrospective changes and against material adverse changes during a fixed paid term.

A1.3 Order of precedence. A signed Order Form or government schedule prevails over this Schedule only to the extent it expressly overrides an identified provision. The Data Processing Addendum (DPA) governs the processing of Customer Personal Data, including Customer Personal Data handled through the Payment Features. Within its subject matter, this Schedule prevails over the Terms and the Acceptable Use Policy. On every other matter, the Terms and the order of precedence in section 2 of the Terms apply.

A1.4 What is not part of the Schedule. Part B, in-product payment notices, receipts and help articles explain the Payment Features to payers. They are informational. They are not contract-acceptance documents and do not add to or reduce the Institution's or Academyship's obligations under this Schedule. Academyship remains responsible for the accuracy of the information it publishes.

A1.5 Transaction authorisations. A Payer's confirmation of a Payment, approval of a PayTo agreement or choice to turn on an Automatic Payment is a separate authorisation for that transaction. It is given to the Institution (and, for PayTo, approved through the Payer's bank), recorded with its own details, and governed by its own terms and the law. This Schedule does not create or replace those authorisations. An Institution's acceptance of this Schedule is not a Payer's authorisation.

A1.6 Plans and configuration. A Payment Feature applies to an Institution only if it is included in the Institution's plan or Order Form and has been enabled for the Institution. Not every feature described here is included in every plan or enabled in every portal.

#A2Definitions

Capitalised terms not defined here have the meanings given in the Terms and the DPA. In this Schedule:

• Fees — Academyship's own charges to the Institution under the Terms and Order Form, such as subscription charges, usage credits (for example, SMS or AI usage), add-ons and professional services.
• Institution Charges — amounts an Institution charges its students, payers or others, such as tuition and course fees, instalments, canteen purchases, Meal Plans, library fines, booking and event fees, and card replacement charges.
• Payment — a payment of an Institution Charge, or an amount added to a Wallet Balance, made through the Payment Features.
• Payer — a person who makes or authorises a Payment, such as a student, parent, guardian, sponsor or employer. A Payer is not a party to the Terms or this Schedule merely because of making a Payment.
• Payment Features — the payment, PayTo, wallet, campus card and meal plan features of the Academyship platform, to the extent they are included in the Institution's plan or Order Form and enabled for the Institution.
• Module Activation — the enabling of a Payment Feature for an Institution, through Academyship's institutional acceptance process, by an Institution representative with authority to bind the Institution, where that process identifies this Schedule by name and version.
• Stripe — the Stripe entity that provides payment services under Stripe's terms, whether to the Institution (for Payments) or to Academyship (for Fees).
• Connected Account — the Stripe connected account that Academyship creates for the Institution when the Institution signs up. It is the Institution's own account, connected to Academyship's Stripe platform, and Payments, including money added to Wallet Balances, are processed through it.
• Payment Mandate — a Payer's authority for the Institution to request payments from the Payer's account, including a PayTo agreement. A Payment Mandate is an authority to request payments. It is not a payment, and it is not the underlying debt.
• Automatic Payment — a payment the Payment Features start without the Payer confirming each one, such as an automatic wallet top-up or a scheduled instalment charged to a saved payment method.
• Wallet Balance — the value recorded in a wallet in the Payment Features that can be spent on purchases the Institution permits. The Institution issues Wallet Balances and is responsible for honouring and repaying them (A13.1).
• Campus Card — a physical or digital card, tag or number issued by or for the Institution and linked to a student's account or wallet, for example by a card number or chip identifier (UID). A Campus Card is not a bank card.
• Meal Plan — a food-service arrangement the Institution sells, such as a set number of meals in a period. A Meal Plan is an Institution Charge, not an Academyship subscription.
• Transaction Record — the record in the Payment Features of a Payment, refund, dispute, Wallet Balance entry or Payment Mandate event.

#A3Parties and money flows

A3.1 Roles. The table below sets out who is involved in a Payment.

A3.2 Seller of record and Connected Account. When an Institution signs up, Academyship creates a Stripe connected account for the Institution (its Connected Account). Stripe is the payment processor. The Institution is the seller, or merchant, for its own Institution Charges: the Payment Features are designed so that the Institution's Connected Account, connected to Academyship's platform, is the seller of record for each Institution Charge, and Payments are processed by Stripe for the Institution. The Connected Account is provided by Stripe on Stripe's terms for connected accounts, which the Institution accepts when Academyship creates the account at sign-up. Stripe may need identity and business details from the Institution, and the Institution must provide them. The Institution's relationship with Stripe, including account approval, identity verification, payouts and reserves, is governed by those terms.

A3.3 Academyship's part. Academyship does not hold or receive Payments or money added to Wallet Balances, and takes no share of them. That money is paid into the Institution's Connected Account. This Schedule does not say that Academyship has no involvement in, or responsibility for, Payments. Academyship's software creates payment, refund and Payment Mandate instructions on the Institution's instructions or a Payer's authorisation, sends them to Stripe and records the results. Academyship is responsible for its part in that process as A16 sets out.

A3.4 Academyship's Fees are separate. Academyship collects its own Fees from the Institution through Stripe, with Academyship as the merchant, under the Terms and Order Form. Fees are not Institution Charges, and Academyship does not use the Payment Features to charge Payers for Academyship's Fees.

A3.5 Contractors. Where the Institution engages a contractor to run a service paid for through the Payment Features, such as a canteen operator, the Institution remains responsible to Academyship under this Schedule for Payments made to its Connected Account.

How money moves, step by step

1. Charge. The Institution creates an Institution Charge in the Payment Features (for example, an invoice, instalment or canteen item), or makes a wallet top-up available.
2. Confirmation. The Payer sees the details listed in A6.1 and confirms. For a card payment, the card details are entered into a Stripe-hosted field or page. For PayTo, the Payer approves the agreement in their own bank (A8).
3. Processing. Academyship's software sends the payment request to Stripe for the Institution's Connected Account. Stripe requests the money through the card network or the Payer's bank. Money added to a wallet is processed in the same way and is paid into the Institution's Connected Account (A13.1).
4. Result. Stripe reports whether the payment succeeded, failed or is still processing. Academyship updates the Transaction Record and receipt. Bank payments can stay in processing for longer than card payments.
5. Payout. Stripe pays successful Payments out to the Institution's nominated bank account under the Institution's Stripe terms and payout settings. Academyship does not set payout timing.
6. Wallet spending. When a Wallet Balance is spent, for example at the canteen, the wallet record shows the purchase and the balance goes down. No card or bank payment is made at that moment.
7. Refunds. When the Institution approves a refund, Academyship's software sends a refund request to Stripe, which returns the money to the original payment method (A11).
8. Disputes. If a Payer's bank or card issuer raises a dispute, it reaches Stripe and the Institution's Connected Account. The Institution responds as A12 describes.
9. Academyship's Fees. Separately, the Institution pays Academyship's Fees under the Order Form. Any Academyship charge connected with Payments applies only as A6.4 describes.

#A4What can be paid, and how

A4.1 Uses. Where the relevant modules are included in the Institution's plan or Order Form and enabled, the Payment Features can be used to pay Institution Charges, such as invoices and instalments for tuition and course fees, canteen orders and Meal Plans, library fines, and booking and event fees, and to add money to a Wallet Balance. The Institution decides which charges it offers for payment through the platform.

A4.2 Not for Academyship's Fees. Subscription charges, SMS credits, AI usage, certificate or page generation, payroll usage and other Fees are payable by the Institution under the Terms and Order Form. They are not collected from Payers.

A4.3 Payment methods. Payers can pay Institution Charges by card or by PayTo, both processed by Stripe, and by any other payment method the Institution enables. Academyship promotes PayTo as a way to pay Institution Charges. The methods shown to a Payer depend on what Stripe has approved for the Institution's Connected Account and how the Institution has configured each portal and charge. Not every method is offered in every portal or for every charge.

A4.4 Payments made outside the platform. An Institution may record payments it receives in other ways, such as cash or a direct bank transfer. Academyship does not process those payments, and the Institution is responsible for the accuracy of those records.

#A5Authorisation and payer identity

A5.1 Who may authorise. A Payment may be authorised only by a person who holds the payment method or is authorised to use it. A Payment Mandate or other recurring debit may be authorised only by the account holder or a person with authority to operate the account.

A5.2 Portals and relationships. A Payer who pays through a portal does so through an account the Institution has created, invited or authorised. A parent, guardian or other linked person can see and pay only the charges the Institution has authorised for that relationship. A family relationship or a matching email address is not proof of authority. Adult students have their own rights, and custody and safeguarding restrictions apply.

A5.3 Payment links. Where the Institution sends a payment link or uses a quick-pay page, anyone holding the link may be able to see the charge details it shows and pay. The Institution must include only the information needed to identify and pay the charge. A payment link does not give access to any other record.

A5.4 No authority by assertion. An Institution cannot create a Payer's authority by entering or uploading the Payer's card or bank details, by ticking a box for the Payer, or by relying on an enrolment form or general terms that did not specifically authorise the payment arrangement. Institution staff must not approve a PayTo agreement or turn on an Automatic Payment for a Payer. If Institution staff enter a one-off payment for a Payer (for example, during a phone call), the Institution must have the Payer's express authority for that specific payment and amount, and must not write down or keep the Payer's full card details.

A5.5 Paying for someone else. A Payer may pay a charge for someone else, such as a parent paying for a child or an employer paying for an employee's course. The Payer must give accurate payer details. Paying for someone does not by itself give the Payer access to that person's records. Access depends on the Institution's authorisations and the law.

A5.6 Children. Where a student is a child, the Institution should configure who may add money, what the student may buy and any limits. A child's ability to spend a Wallet Balance is not authority to charge a parent's or guardian's payment method.

A5.7 Records of authorisation. For each Payment, Payment Mandate and Automatic Payment set-up, Academyship will record the details shown to the Payer, the account that confirmed it, the time and the result, and will make that record available to the Institution for reconciliation, disputes and Payer enquiries.

#A6Amounts, pricing and receipts

A6.1 Before confirmation. Before a Payer confirms a Payment, the Payment Features show:

• the Institution's name;
• what the Payment is for;
• the amount of the underlying Institution Charge;
• GST, where it applies;
• any discount, waiver or credit applied;
• any separately identified fee permitted under A7;
• the total amount that will be charged, and the currency; and
• whether the Payment is one-off or part of a recurring or instalment arrangement, and if so its schedule.

A6.2 Total charged. The amount charged for a Payment will not exceed the total the Payer confirmed. For a recurring or instalment arrangement, each amount will not exceed what the Payer authorised.

A6.3 The Institution sets its prices. The Institution sets Institution Charges, discounts and their GST treatment, and is responsible for their accuracy and lawfulness, including under the Australian Consumer Law's pricing rules. Academyship displays and charges amounts as the Institution configures them, and is responsible for doing that accurately.

A6.4 No share of Payments. Academyship does not hold or receive Payments or money added to Wallet Balances, takes no share of them and does not deduct any amount from them. Any Academyship charge for the Payment Features is a Fee. It applies only if the Institution's plan or Order Form states it, and it is charged to the Institution, not taken from Payments.

A6.5 Processing fees. Payments attract a payment-processing fee. The processing fee for each payment method is shown in the Institution's plan or Order Form. The Institution decides whether it bears the processing fee itself or passes it to Payers, but it may pass it to Payers only as A7 permits. A processing fee passed to a Payer is shown to the Payer before they confirm (A6.1).

A6.6 Receipts and tax invoices. Receipts generated through the Payment Features are issued in the Institution's name and show the amount, any separately identified fee, the payment method, the date, a reference and the status. A receipt for a Payment that is still processing is not confirmation that the money has been received. The Institution is responsible for issuing any tax invoice the law requires for an Institution Charge.

#A7Card surcharges and processing fees

A7.1 The current rule. From 1 October 2026, no-surcharge rules apply to payments made with Visa, Mastercard, American Express and eftpos cards in Australia, as explained by the ACCC and the Reserve Bank of Australia.

A7.2 No card surcharges. The Institution must not pass card processing fees to Payers for card payments, whatever card is used, or otherwise impose a card surcharge prohibited by law or card scheme rules. This applies whether the surcharge would be added through the Payment Features or in any other way, including by charging a Payer a higher price for an Institution Charge because the Payer pays by card.

A7.3 No relabelling. Passing a card processing fee to a Payer is a card surcharge, however it is labelled. A charge that applies because a Payer pays by card is a card surcharge, whether it is called a "processing fee", a "convenience fee", a service or administration fee, or anything else. It is not permitted under this Schedule.

A7.4 PayTo and other non-card methods. The Institution may choose to pass the PayTo processing fee to Payers, but only if the fee is clearly shown to the Payer before the Payer confirms. The setting in the Payment Features that lets the Institution choose who bears the processing fee may be used to pass a fee to Payers only for PayTo or another non-card payment method, and only where that is lawful. It must not be used for card payments.

A7.5 Conditions for any fee passed to Payers. Any fee passed to Payers under A7.4 must be lawful; shown clearly as a separate line, with its name and amount, before the Payer confirms; included in the total shown under A6.1; and not misleading about what it is for. The Institution is responsible for its choice of who bears a processing fee, and for that choice being lawful.

A7.6 Corrections. If a Payer is charged a surcharge or fee that this Schedule or the law does not permit, the Institution will refund it. Where the charge resulted from a defect in the Payment Features, Academyship will correct the defect and help the Institution identify and remediate the affected Payments (A16).

A7.7 Rule changes. Academyship will update the Payment Features where needed to comply with changes to law or card scheme rules that affect how Payers are charged, and will tell Institutions about changes that affect what Payers see or pay.

#A8PayTo agreements and Payment Mandates

A8.1 What PayTo is. Where the Institution offers PayTo, a Payer can authorise the Institution to request payments directly from the Payer's bank account. The Payer approves a PayTo agreement in their own bank's app or online banking. Payments under PayTo agreements are processed by Stripe for the Institution's Connected Account under Stripe's PayTo terms.

A8.2 Agreement details. Each PayTo agreement created through the Payment Features identifies the Institution as the creditor, by a name the Payer will recognise; the purpose of the payments; a fixed amount or a maximum amount per payment; the frequency; the start date; and the end date or expiry, if there is one. The Institution is responsible for these details being accurate and matching the underlying Institution Charges.

A8.3 Authority is not payment. An approved PayTo agreement is an authority to request payments. It is not a payment. Each payment request is a separate transaction that can succeed, fail or remain processing (A10). A Transaction Record shows money as received only when the payment has succeeded.

A8.4 Amendments. The Institution cannot increase the amount, increase the frequency, extend the end date or change the purpose of a PayTo agreement without the Payer's approval through their bank. Until the Payer approves a change, only the existing approved terms apply.

A8.5 Payment requests and retries. The Institution may request payments only within the agreement's amount, frequency, dates and purpose, and only for amounts actually due. If a payment fails, any further attempt must also be within the agreement and must not collect more, or more often, than the agreement allows. The Payer's bank checks payment requests against the agreement.

A8.6 Pause, resume and cancellation. A Payer can pause, resume or cancel a PayTo agreement through their bank at any time. The Institution can also pause or cancel an agreement, as the PayTo process allows. A pause or cancellation applies to payments not yet requested; a payment already in progress may still complete. The Institution must not request payments under a paused or cancelled agreement.

A8.7 Debts and debit authority are separate. Ending a PayTo agreement stops future payment requests under it. It does not by itself cancel an amount the Payer validly owes the Institution, and the Institution may ask the Payer to pay another way. Equally, if the underlying debt ends or reduces, for example because it is paid in full, waived, cancelled or reduced, the Institution must promptly cancel or amend the agreement so that it requests no more than what is due, and must refund any amount collected that was not due.

A8.8 Contact and records. The Institution must give Payers a working way to contact it about a PayTo agreement. Academyship will record the agreement details presented to the Payer, the approval result, each status change and each payment request, and will make those records available to the Institution.

A8.9 Rights preserved. Nothing in this Schedule limits a Payer's rights under their bank's terms, Stripe's PayTo terms or the law, including the right to pause or cancel a PayTo agreement through their bank.

Stages of a PayTo agreement

#A9Automatic payments and wallet top-ups

A9.1 What Automatic Payments are. The Payment Features offer two kinds of Automatic Payment, which the Institution can enable for its portals: automatic wallet top-up, which charges a payment method the Payer has saved when the Wallet Balance falls below the amount the Payer agreed to; and scheduled payments, such as instalments, which charge a saved payment method on the dates the Payer agreed to. The Institution decides whether to offer them. Each Payer decides whether to use them, as A9.2 to A9.6 describe.

A9.2 Separate opt-in. An Automatic Payment is set up only when the Payer separately and expressly turns it on. It is never turned on by default, by a pre-ticked box, by accepting general terms or by an Institution administrator. No Automatic Payment is charged unless the Payer has turned it on.

A9.3 What the Payer sees and agrees to. Before turning on an Automatic Payment, the Payer is shown, and agrees to: the Institution's name; the trigger (for example, the balance falling below a stated amount, or a stated date); the amount of each payment; the maximum number or total of payments in a stated period; the payment method that will be charged; what happens if a payment fails; and how to turn it off.

A9.4 Limits and confirmations. An Automatic Payment will not exceed the amount, trigger, frequency or maximum the Payer set. The Payer receives a confirmation when the Automatic Payment is set up and a receipt for each payment.

A9.5 Failed payments. If an Automatic Payment fails, for example because of insufficient funds or an expired card, it is not retried beyond what the Payer agreed under A9.3, the Payer is told about the failure, and the Wallet Balance is not increased for a payment that did not succeed.

A9.6 Turning it off. A Payer can turn off an Automatic Payment at any time in the portal where it was set up, or by asking the Institution. Turning it off stops payments that have not yet started. An Automatic Payment also stops when its payment method is removed, the wallet is closed or the student's account ends.

A9.7 PayTo-funded payments. Where an Automatic Payment is made under a PayTo agreement, A8 also applies.

#A10Payment statuses

A10.1 What each status means. The Payment Features and receipts use the statuses below, or labels with the same meaning.

A10.2 Confirmation screens are not settlement. A confirmation screen or message after a Payer confirms a Payment shows that the request was received. Only a Paid status shows that the payment succeeded. Academyship does not promise when a payment will complete or when Stripe will pay out funds, because these depend on Stripe, banks and payment networks.

A10.3 Duplicate and stuck payments. If a Payer reports a possible duplicate, or a payment that has stayed in Pending or Processing, the Institution checks the Transaction Records and its Stripe account before asking the Payer to pay again. If the Payer has been charged twice for the same amount owed, the Institution refunds the duplicate. If a duplicate or stuck payment appears to result from a fault in the Payment Features, the Institution should report it to Academyship support, and Academyship will investigate and help correct the records.

A10.4 Reconciliation. The Institution is responsible for reconciling Transaction Records with its Stripe account and bank account. Academyship will make Transaction Records available through reports or exports in the Payment Features to support reconciliation.

#A11Refunds, credit notes, waivers and cancellations

A11.1 Who decides. The Institution decides whether to refund, credit, waive or cancel an Institution Charge, under its own policies and the law. That includes the consumer guarantees in the Australian Consumer Law and any sector-specific refund rules that apply to the Institution, such as rules for overseas students or government-funded training. Academyship does not decide refunds of Institution Charges.

A11.2 Academyship's Fees are different. Refunds of Academyship's own Fees are governed by section 10 of the Terms and the Order Form, not this section.

A11.3 Who starts a refund. Refunds are started in the Payment Features by Institution users whose role permits it. A Payer's request for a refund is not a refund decision; the Institution decides it. Academyship will not start a refund of an Institution Charge except on the Institution's instruction or where the law requires it.

A11.4 Requested is not refunded. An approved refund is sent to Stripe and shows as Refund pending. It shows as Refunded only when Stripe reports that it succeeded. If Stripe cannot complete it, the refund shows as failed, the Institution is told, and the Institution must arrange another way to repay the Payer.

A11.5 Where the money goes. A refund is returned to the original payment method. If that is not possible (for example, because the card account has closed), or the Payer asks for another method and the Institution agrees, the Institution repays the Payer another way. A refund is credited to a Wallet Balance instead only if the Payer agrees, or if the original purchase was paid from that Wallet Balance.

A11.6 Partial refunds. The Institution may refund part of a Payment. Total refunds cannot exceed the amount paid.

A11.7 Provider costs. The Institution may deduct payment-provider costs from a refund only where the law permits it and the deduction was clearly disclosed to the Payer before the Payment was made.

A11.8 Effect on what is owed. A refund returns money. It does not by itself change what the Payer owes. The Institution must update the underlying Institution Charge, for example by issuing a credit note or cancelling the invoice, so that the Payer's account is accurate. It must also stop any Payment Mandate or Automatic Payment that would otherwise collect an amount that is no longer due (A8.7).

These are different actions

#A12Disputes, chargebacks and unauthorised payments

A12.1 Where issues go. Questions about whether a charge is owed, its amount or a refund decision are for the Institution. Suspected unauthorised or fraudulent payments, and disputes a Payer raises with their card issuer or bank, are handled through the Payer's bank or card issuer, Stripe and the Institution. Faults in the Payment Features are for Academyship, through the Institution or support@academyship.com.au. Suspected security incidents go to security@academyship.com.au.

A12.2 Payers' dispute rights are preserved. The Institution must not ask a Payer to give up, or penalise a Payer for using, their right to dispute a payment or seek a chargeback through their bank or card issuer. Nothing in this Schedule limits those rights. Neither the Institution nor Academyship will treat a good-faith dispute as misuse of the platform, and Academyship will not restrict a Payer's or student's access to the platform merely because a Payer has raised a dispute.

A12.3 Responding to disputes. The Institution responds to disputes through its Stripe account and the Payment Features. Academyship will make the relevant Transaction Records available to support the response. Evidence should be limited to what is needed to show the charge, the authorisation and what was supplied. The Institution must not submit unnecessary student information, such as results, behaviour, health or welfare records, as dispute evidence.

A12.4 Responsibility for reversals. As between Academyship and the Institution, the Institution is responsible for chargebacks, reversals, dispute fees, refunds and any negative balance arising from Payments to its Connected Account, except to the extent caused by Academyship's breach of this Schedule or the Terms, or by Academyship's negligence. If Stripe recovers such an amount from Academyship, the Institution will reimburse Academyship on request, with supporting details.

A12.5 Suspected unauthorised use. If an account, Campus Card or payment method may have been misused, the Institution should promptly lock the affected Campus Card or wallet, restrict the affected access and tell the account holder. If the misuse may involve a compromise of the platform, the Institution must report it to Academyship promptly. Academyship will investigate platform-related causes and handle any Security Incident as the DPA requires.

A12.6 Correcting errors. The Institution corrects errors in its Institution Charges and Transaction Records. Corrections are made by adding a correcting entry, not by deleting or overwriting the original record. Where an error results from a defect in the Payment Features, Academyship will correct the defect and help the Institution identify and correct the affected records (A16).

#A13Wallet balances

A13.1 Who issues Wallet Balances and holds the money. The Institution is the issuer of Wallet Balances and the party obliged to honour them. Money added to a wallet is paid to the Institution through its Connected Account (A3) and is held in the Institution's own account. A Wallet Balance is the Institution's obligation to supply permitted purchases up to that value, or to repay it under A13.8. The Institution must honour, refund and close Wallet Balances under its own wallet rules and the law. Academyship provides the software that records Wallet Balances. It does not hold or receive the money added to wallets and takes no share of it.

A13.2 What a Wallet Balance is not. A Wallet Balance is a record of prepaid value that can be spent on purchases the Institution permits. It is not a bank deposit or a bank account. It is not insured or guaranteed by any government scheme. Academyship does not hold the money added to wallets, in trust, in escrow or in any other way. A Wallet Balance is not cash and cannot be withdrawn or transferred except as A13.6 and A13.8 allow.

A13.3 Legal requirements. The Institution is responsible for meeting any legal requirements that apply to its operation of wallets and Wallet Balances. The Institution must not describe Wallet Balances to Payers in a way that is inconsistent with A13.1 or A13.2.

A13.4 Spending. A Wallet Balance can be spent only on purchases the Institution has enabled, such as canteen purchases, and within any spending limits, restrictions or locks set for that wallet. The Institution decides which purchases are permitted and who may set limits. Where a parent or guardian can set limits for a child, they can do so only within the relationship the Institution has authorised.

A13.5 Access. Students, parents, guardians and other Payers can see a Wallet Balance and its history only as the Institution has authorised. Adult students have their own rights. Adding money to a student's wallet does not by itself give a Payer access to the student's other records.

A13.6 Funding and transfers. Money is added to a Wallet Balance by a Payment (A6) or by an automatic wallet top-up the Payer has turned on (A9). The Institution may credit a Wallet Balance, for example for a refund, with a recorded reason. Where the Institution enables transfers between wallets, a transfer may be made only by a person authorised for both wallets, is recorded in both wallets' histories, and can be corrected if made in error. A Wallet Balance cannot be transferred outside the Institution's wallets.

A13.7 Wallet records. Every change to a Wallet Balance is recorded as a separate entry showing the amount, date, reason and the person or process that made it. Errors are corrected by a correcting entry, not by editing or deleting the history.

A13.8 Repaying unused balances. The Institution must repay an unused Wallet Balance on request when the student leaves the Institution, the wallet is closed or wallet services end. Repayment is made to the person entitled to it, ordinarily the Payer who funded it, normally to the payment method used or as that person directs. The Institution may offer repayment at other times. Any conditions on repayment must be lawful and shown to Payers before they add money. A Wallet Balance does not expire and is not forfeited unless a lawful rule to that effect was clearly shown to the Payer before the money was added. If a balance cannot be repaid because the person entitled to it cannot be found, the Institution must deal with it as the law requires, which may include unclaimed-money laws.

A13.9 Not security for Fees. Wallet Balances are not available to Academyship as security for, or to pay, the Institution's Fees (A18.4).

What happens to a Wallet Balance when circumstances change

#A14Campus cards and meal plans

A14.1 Campus Cards. A Campus Card identifies a student so that purchases can be recorded against their wallet or account. It is not a bank card, does not hold money itself and is not a payment-card credential. A card number or chip identifier is personal information linked to the student, and the Institution must protect it accordingly. What is printed on a card is covered in the education operations schedule.

A14.2 Issuing, locking and replacing cards. The Institution issues, locks, unlocks and replaces Campus Cards. It must lock a card promptly after it is reported lost or stolen, and must tell students and Payers how to report a lost card. Any replacement charge is an Institution Charge and is shown before it is charged.

A14.3 Authorised spending. A purchase with a Campus Card is authorised only within the wallet's permitted purchases, limits and restrictions (A13.4). Presenting a card does not authorise a purchase that a limit or restriction blocks.

A14.4 Meal Plans. A Meal Plan is the Institution's food-service product, not an Academyship subscription. Before purchase, the Institution must show the Meal Plan's price, period and inclusions; whether and how it renews; how to cancel; and what happens to meals not used or orders not collected. A Meal Plan is not renewed or charged again unless the Payer agreed to renewal when buying it, or renews it themselves. Automatic renewal is an Automatic Payment under A9.

A14.5 Cancellation and uncollected orders. Meal Plan cancellation, unused meals and uncollected orders are governed by the Institution's Meal Plan or canteen terms and the law. This Schedule does not create any rule that unused meals or uncollected orders are forfeited. The Institution must not apply such a rule unless it is lawful and was clearly shown before purchase.

A14.6 Items not supplied. If the Institution cannot supply an item or meal that was paid for, for example because it is out of stock, the Institution must refund the amount paid for it or, if the Payer agrees, provide a substitute or a wallet credit.

A14.7 Food safety and dietary information. The Institution, or the canteen operator it engages, is responsible for food safety, allergen management, ingredients, preparation, stock and delivery. Dietary and allergy settings in the Payment Features can help staff see recorded restrictions. They do not make food allergen-free and do not replace the Institution's own allergy management and emergency procedures. Dietary and allergy information can be health information and can reveal religious or cultural beliefs. It must be handled as the DPA and the Institution's privacy obligations require. The education operations schedule covers canteen operations in more detail.

#A15Institution responsibilities

In addition to its responsibilities elsewhere in this Schedule and the Terms, the Institution is responsible for:

• the lawfulness, accuracy and fairness of its Institution Charges, prices, discounts, payment plans, late fees, Meal Plan terms and wallet rules, including under the Australian Consumer Law and any sector-specific rules;
• accurate debtor and Payer details, and linking each charge to the right student and Payer;
• keeping its Connected Account in good standing, giving Stripe the identity and business details it needs, and complying with Stripe's terms for connected accounts, card scheme rules and PayTo requirements;
• deciding who bears the processing fee, not passing card processing fees to Payers, and not imposing card surcharges or other impermissible fees (A7);
• the authority behind each Payment Mandate and Automatic Payment, and stopping debits when an amount is no longer due (A8, A9);
• refund, credit, waiver and cancellation decisions, and processing them promptly (A11);
• responding to disputes and chargebacks (A12);
• issuing any tax invoices and receipts the law requires, and the GST treatment of its charges;
• reconciling Transaction Records with its Stripe and bank accounts (A10.4);
• giving payment, refund and wallet permissions only to appropriate staff, and reviewing them regularly;
• giving Payers its privacy collection notice, its own payment, refund, wallet and Meal Plan terms, and a working contact route for payment questions and complaints;
• handling hardship requests and complaints about Institution Charges under its own policies and the law;
• its obligations as issuer of Wallet Balances, including honouring, refunding and closing them under its wallet rules and the law, and meeting any legal requirements that apply to operating its wallets (A13); and
• the conduct of any contractor it engages to operate a service paid for through the Payment Features.

#A16Academyship responsibilities

Academyship remains responsible for its own conduct and for the Payment Features. In particular, Academyship will:

• provide the Payment Features with due care and skill, as section 25 of the Terms provides;
• display amounts, fees and payment terms as the Institution configures them and as this Schedule requires, and charge no more than the Payer confirmed (A6);
• not itself impose a card surcharge on Payers, and update the Payment Features where needed to comply with the law and card scheme rules on surcharges (A7);
• create payment, refund and Payment Mandate instructions accurately, and only on the Institution's instructions or a Payer's authorisation;
• keep accurate Transaction Records and authorisation records (A5.7, A8.8) and make them available to the Institution;
• protect information handled through the Payment Features under the DPA, including the measures in its Annex II;
• notify the Institution of a Personal Data Breach as the DPA requires, and tell affected Institutions promptly about a known fault in the Payment Features that has caused, or is likely to cause, incorrect charges, refunds or Wallet Balances;
• correct defects in the Payment Features, and help the Institution identify and remediate the affected Payments and records;
• comply with the Stripe platform terms that apply to Academyship's operation of the Payment Features; and
• not use information about Payers for Academyship's own marketing or advertising.

Academyship's liability in connection with the Payment Features is governed by the Terms, including section 27. This Schedule does not exclude it. Nothing in this Schedule makes Academyship a bank, a lender, the supplier of the Institution's education or other services, or a party to the debt between the Institution and a Payer.

#A17Data, records and service dependencies

A17.1 Information handled. The Payment Features handle:

• Payer and student names and contact details, and the link between a Payer, a student and a charge;
• Institution Charges, invoices and receipts;
• payment-method information returned by Stripe, such as card brand, last four digits and expiry, or masked bank account details;
• Stripe customer, payment and Payment Mandate identifiers;
• Transaction Records, including refunds and disputes;
• Payment Mandate details and status history;
• Wallet Balances and wallet histories, spending limits and locks;
• Campus Card numbers or identifiers; and
• Meal Plan and order details, including any special instructions and, where the Institution records them, dietary or allergy restrictions.

A17.2 Card details. Where card details are entered into a Stripe-hosted payment field or page, they go to Stripe rather than being stored by Academyship. Academyship receives back limited information about the card and the payment, as listed in A17.1.

A17.3 Roles and locations. Academyship handles this information for the Institution under the DPA. Academyship hosts Customer Data in Sydney, Australia (ap-southeast-2). Stripe handles payment information to provide its services under its terms with the Institution, and also for its own purposes, such as fraud prevention, identity verification and legal compliance, under its own privacy policy. Stripe's role differs by function. Stripe's processing may involve countries outside Australia, including the United States and India, as Stripe's privacy policy describes. The Privacy Policy and Subprocessor Register explain Academyship's handling and providers.

A17.4 Retention. Transaction Records, authorisation records and wallet histories are kept in the Institution's Tenant while it is active and as the Institution directs, subject to legal holds and legal retention requirements. Export and deletion after termination follow section 23 of the Terms and the DPA. The data retention schedule explains how these records fit into the wider lifecycle. The Institution is responsible for keeping the financial records the law requires it to keep. Stripe and banks keep their own records under their own obligations, and deleting records from Academyship does not delete those copies.

A17.5 Service dependencies. Payments depend on Stripe, card networks, banks and the systems that support PayTo. An outage or delay in any of them can delay payments, refunds, Payment Mandate changes or status updates, and is outside Academyship's control. Academyship does not promise settlement, refund or payout times. Academyship remains responsible for the availability and correct operation of its own software as the Terms provide.

A17.6 Contact. Institutions can contact support@academyship.com.au about the Payment Features, security@academyship.com.au about a suspected security incident, and privacy@academyship.com.au about privacy. Do not send full card numbers, bank passwords or one-time codes to any of these addresses.

#A18Suspension, ending the payment features and changes

A18.1 Notice. Academyship will give an Institution the notice the Terms require before it removes or ends a Payment Feature, so that the Institution can tell Payers and make other arrangements.

A18.2 When the Payment Features end. When the Payment Features end for an Institution, whether on termination, expiry or removal of the module:

• Academyship will stop creating new payment requests under Payment Mandates and Automatic Payments made through the Payment Features;
• the Institution must tell affected Payers, cancel or move Payment Mandates as the PayTo process allows, complete or arrange refunds, and repay or otherwise lawfully deal with Wallet Balances (A13.8); and
• Academyship will make Transaction Records, authorisation records and wallet histories available for export as section 23 of the Terms provides.

A18.3 Suspension. If Academyship suspends the Institution's access under section 29 of the Terms, Academyship will tell the Institution which Payment Features are affected and will, where reasonably possible, allow the Institution to continue to issue refunds, respond to disputes and export Transaction Records during the suspension. A suspension does not prevent a Payer from pausing or cancelling a PayTo agreement through their bank.

A18.4 Payers' money is not collateral. Academyship will not use Payments, Wallet Balances or Payers' money as security for, or to pay, the Institution's Fees. Academyship will not withhold an otherwise available export of Transaction Records or wallet histories solely because of a good-faith billing dispute.

A18.5 Changes. Changes to this Schedule take effect only as A1.2 describes.

#Part BGuide for payers

This part is for parents, guardians, students, sponsors, employers and anyone else paying an education Institution through Academyship. It explains in plain language how payments, PayTo agreements, wallets, campus cards and meal plans work. It is information only. You are not agreeing to anything by reading it, and it does not change your rights. Your Institution's own payment terms, and the details shown to you when you pay, also apply.

#B1Who you are paying

When you pay a fee, invoice, canteen order or wallet top-up through Academyship, you are paying your Institution, such as your school, college, university or training organisation. The Institution sets the amount, provides the education, meal or other service, and decides refunds.

• Academyship makes the software the Institution uses. Academyship is not selling you anything, is not the organisation you owe money to, and does not decide what you owe or whether you get a refund. You do not become an Academyship customer by paying.
• Stripe is the payment company that processes the payment for the Institution. Your money goes to the Institution's own account. Academyship does not receive it or take a share of it.
• Your bank or card issuer sends the payment. Contact them about any payment you did not authorise.

You can pay for someone else, such as your child or an employee. Please give your own correct details as the payer. Paying for someone does not by itself let you see their records. What you can see is set by the Institution, and adult students have their own rights.

#B2Before you pay

Before you confirm a payment, you should see:

• the Institution's name;
• what the payment is for;
• the amount, any GST, and any discount or credit applied;
• any separate fee, shown on its own line;
• the total you will be charged, and the currency; and
• whether it is a one-off payment or part of a regular or instalment arrangement, and if so the schedule.

You will be charged no more than the total you confirm. For regular payments, each payment cannot be more than you agreed to.

If something is missing or looks wrong, do not pay yet. Contact the Institution first. If you cannot use the online payment page, for example because of a disability or because you do not have a suitable device, ask the Institution about other ways to pay.

#B3Paying by card, and fees

You can pay by card or by PayTo, and by any other method your Institution offers.

From 1 October 2026, no-surcharge rules apply to payments made with Visa, Mastercard, American Express and eftpos cards in Australia (see the ACCC's card surcharges guidance). A charge for paying by card is a surcharge even if it is called a processing fee, a convenience fee or a service fee. If you are asked to pay an extra fee for paying by card, contact the Institution.

If you pay by PayTo, the Institution may ask you to pay a processing fee. If it does, the fee is shown on its own line, with its name and amount, before you confirm, and it is included in the total.

When you type card details into a payment field or page provided by Stripe, those details go to Stripe rather than being stored by Academyship. The Institution and Academyship see limited details, such as the card type and last four digits.

#B4PayTo agreements

PayTo lets you allow the Institution to take payments from your bank account, for example for instalments. Where your Institution offers it:

• You approve it in your own banking app or online banking. Nothing is taken until you approve. Nobody at the Institution can approve it for you.
• Check the details. The agreement shows who will take the payments, what they are for, the amount or maximum amount, how often, and the start and end dates.
• Changes need your approval. The Institution cannot increase the amount or frequency, or extend the agreement, unless you approve the change in your bank.
• You stay in control. You can pause, resume or cancel the agreement in your banking app at any time. This affects payments that have not started yet; one already in progress may still go through.
• Cancelling the agreement does not cancel what you owe. If you still owe the Institution money, you will need to pay another way. Please tell the Institution when you pause or cancel, so it can help you arrange that.
• If you no longer owe the money, for example because you have paid in full or the charge was cancelled, the Institution must stop taking payments and refund anything it took that was not due.
• An approved agreement is not a payment. Each payment under it is separate and can succeed or fail (see B6).

#B5Automatic top-ups and scheduled payments

Automatic top-up adds money to a wallet when the balance falls below an amount you agree to, by charging a card or account you have saved. Scheduled payments, such as instalments, charge a saved card or account on dates you agree to. Your Institution decides whether to offer them in your portal. Either one happens only if you turn it on yourself. They are never on by default, and Institution staff must not turn them on for you.

Before you turn one on, you will see the Institution's name, the amount of each payment, when a payment will happen (for example, the balance level or the dates), the most that can be charged in a period, which card or account will be used, what happens if a payment fails and how to turn it off. You will get a confirmation when you set it up and a receipt for each payment.

You can turn it off at any time in your portal, or by asking the Institution. This stops payments that have not started. It also stops if you remove the saved card or account, the wallet is closed or the student's account ends. If a payment fails, it is not retried beyond what you agreed to, and you will be told. A failed top-up does not increase your wallet balance, and a failed scheduled payment leaves that amount unpaid. If the payments are made under a PayTo agreement, B4 also applies.

#B6What your payment status means

• Pending or Processing — your payment has not finished. Do not pay again while it shows this status.
• Paid — the payment succeeded. Keep your receipt.
• Failed or Cancelled — the payment did not go through, and the amount is still owed. Find out why before trying again, or use another method.
• Refund pending — a refund is on its way but has not finished.
• Refunded — the refund has been sent. It can take some time to appear on your statement.
• Disputed — your bank or card issuer is looking into the payment.

A "thank you" screen means your payment request was received, not that the payment has finished. Bank payments can take longer than card payments. If a payment seems stuck, or you think you have paid twice, check your receipt and payment status, and contact the Institution before trying again. If you were charged twice for the same amount, the Institution will refund the extra payment.

#B7Refunds

Your Institution decides refunds of its charges, under its own refund policy and the law. You may have rights under the Australian Consumer Law, and some kinds of education have their own refund rules. Academyship does not decide refunds of Institution charges.

• A refund normally goes back to the card or account you paid with. It goes to a wallet instead only if you agree, or if you paid from that wallet.
• A refund request is not a refund. A refund is finished only when the status shows Refunded.
• A refund, a credit note, a waiver and a cancelled invoice are different things. The table in section A11 explains how they differ.
• Payment-provider costs can be kept from a refund only if the law allows it and you were told clearly before you paid.

#B8Problems, disputes and unauthorised payments

• You disagree with a charge or amount. Contact the Institution.
• A payment you did not authorise, or lost or stolen card or bank details. Contact your bank or card issuer straight away. Tell the Institution too, and ask it to lock any campus card.
• You keep your rights. You can always use your bank's or card issuer's dispute process, including asking for a chargeback where it applies. Neither the Institution nor Academyship can make you give up those rights, and Academyship will not restrict your access to the platform because you raised a genuine dispute.
• The payment page is not working. Tell the Institution. If it cannot help, or your concern is about Academyship itself, contact support@academyship.com.au.
• Your bank's response. If you are not satisfied with how your bank handles your complaint, you may be able to take it to the Australian Financial Complaints Authority (AFCA). AFCA deals with complaints about its member financial firms, such as banks. Whether it can help depends on who your complaint is about.

Never send a full card number, bank password or one-time code by email, including to Academyship or your Institution.

#B9Wallets, campus cards and meal plans

Wallets. A wallet balance is prepaid credit for purchases your Institution allows, such as canteen food. Your Institution issues the wallet balance and is responsible for honouring and repaying it. The money you add is paid to the Institution and held in its own account (see section A13.1). Academyship does not hold that money. A wallet balance is not a bank account or a deposit, it is not insured or government-guaranteed, and it cannot be spent elsewhere or withdrawn as cash except through a repayment. If the Institution stopped trading, you might not get all of your balance back, so consider topping up only what you expect to use.

You can see a wallet's balance and history if the Institution has given you access. Ask the Institution about spending limits. When a student leaves, or a wallet is closed, you can ask for the unused balance to be repaid. A balance does not expire or get forfeited just because it is unused, unless a lawful rule was clearly shown to you before you added the money.

Campus cards. A campus card (or tag) identifies the student for purchases. It is not a bank card and does not hold money. If it is lost or stolen, tell the Institution straight away so it can lock the card. Locking or replacing a card does not change the wallet balance.

Meal plans. A meal plan is bought from your Institution. It is not an Academyship subscription. Before you buy, you should be told the price, the period, what is included, whether it renews, how to cancel and what happens to unused meals. It will not renew and charge you again unless you agreed to that when buying it, or you renew it yourself. If something you paid for cannot be supplied, you are entitled to a refund, or to a substitute or wallet credit if you agree.

Allergies and dietary needs. Recording an allergy or dietary need helps canteen staff see it, but it does not make food allergen-free. Always tell the Institution directly about serious allergies, and keep its medical and emergency arrangements up to date. In an emergency, call 000.

#B10Your information

The Institution collects your details to take your payment, send receipts and keep its financial records, and should give you its own privacy notice. Academyship handles this information for the Institution and hosts it in Sydney, Australia. Stripe receives payment information to process payments and for its own purposes, such as fraud prevention and legal compliance, and may process it outside Australia. Payment records are kept as the Institution's records and the law require.

For questions about the Institution's records, contact the Institution. For questions about Academyship's own handling, contact privacy@academyship.com.au. See Academyship's Privacy Policy and Stripe's privacy policy.

#B11Who to contact

If you need this information in another format, contact accessibility@academyship.com.au.

#02Changes, related documents and version history

Academyship reviews this page when the Payment Features, Stripe arrangements, card scheme rules or relevant law change. A new version of Part A applies to an Institution only as A1.2 describes. Part B is updated so that it stays accurate. Prior versions can be requested from legal@academyship.com.au.

Terms of Service DPA Privacy Policy Subprocessor Register Acceptable Use Support Education Operations Data Retention Complaints