RPS Payment Processing

Overview

The Recurring Payment Schedule (RPS) is Feoda's mechanism for automating payment collection from families. Once a parent sets up their payment method and schedule via the payment suitelet, an RPS record is created in NetSuite. A daily scheduled script processes all RPS records whose processing date matches the current date.

Two payment channels are supported: 1. Credit Card — processed via eway (payment service provider) 2. Direct Debit / Bank — processed via ABA file (Australian bank format)

---

RPS Record Structure

Each RPS record contains:

Field	Description
Debtor	The family record linked to this payment
Invoice/Transaction	The invoice or billing order this payment applies to
Payment Method	Credit card or Direct debit (bank)
Amount	Payment amount for this installment
Processing Date	The date the payment should be processed
Frequency	Weekly, fortnightly, monthly, term, or annual
Status	Pending, Processed, Cancelled, Refunded
Card/Bank Details	Encrypted payment details (credit card number or bank account)
Recurrence	The recurring schedule record linking all installments

Note: The RPS amount may differ from the invoice amount. It can include opening balances, building levy, and other adjustments on top of the standard billing amount.

---

Credit Card Processing (eway)

Flow

┌─────────────┐     ┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  Scheduled   │────▶│  Submit to   │────▶│  Receive     │────▶│  Create      │
│  Script runs │     │  eway API    │     │  Response    │     │  Payment     │
│  (daily)     │     │              │     │  Code        │     │  Record      │
└─────────────┘     └─────────────┘     └─────────────┘     └─────────────┘

Steps

1. Daily script execution: The scheduled script queries all RPS records where:
2. Processing date = today
3. Payment method = Credit Card

4. Status = Pending

5. Submit to eway: For each qualifying RPS, the script sends the payment request to eway with:

6. Card details (from the RPS record)
7. Payment amount

8. Reference information (invoice number, debtor code)

9. Receive authorization response: eway returns:

10. Authorization code 00 = Payment successful

11. Any other code = Payment declined (e.g., insufficient funds, expired card, bank hold)

12. On success (code 00):

13. A payment record is created in NetSuite
14. The payment is applied against the invoice
15. RPS status is updated to Processed

16. The authorization code is stored on the RPS record

17. On failure (non-00 code):

18. The RPS status remains Pending or is marked with the failure reason
19. The decline code and reason are stored on the RPS record
20. The school can see failed payments in monitoring saved searches
21. The parent may need to update their card details

eway Response Codes (Common)

Code	Meaning
00	Approved
05	Do not honour (bank declined)
12	Invalid transaction
14	Invalid card number
51	Insufficient funds
54	Expired card

Full code reference: eway API documentation

---

Direct Debit Processing (ABA File)

Flow

┌─────────────┐     ┌─────────────┐     ┌─────────────┐     ┌─────────────┐     ┌─────────────┐
│  Scheduled   │────▶│  Generate    │────▶│  Upload to   │────▶│  Download    │────▶│  Apply       │
│  Script runs │     │  ABA file    │     │  Bank portal │     │  Bank report │     │  Deposit in  │
│  (daily)     │     │              │     │  (manual)    │     │  (manual)    │     │  NetSuite    │
└─────────────┘     └─────────────┘     └─────────────┘     └─────────────┘     └─────────────┘

Steps

1. Daily script execution: The scheduled script queries all RPS records where:
2. Processing date = today
3. Payment method = Direct Debit / Bank

4. Status = Pending

5. Generate ABA file: The script creates an ABA file containing:

6. Header: School's bank account details (BSB, account number, bank name)
7. Detail records: One entry per payment — parent's BSB, account number, payment amount, reference code
8. Footer: Total record count, total amount

9. The ABA file follows strict Australian banking format standards

10. Upload to bank portal (manual step):

11. The school downloads the generated ABA file from NetSuite
12. Uploads it to the school's bank portal (e.g., ANZ, Westpac, CBA)

13. The bank processes the direct debit requests (typically overnight)

14. Download bank report (manual step):

15. After the bank processes the file, the school downloads the response report

16. The report indicates which transactions were successful and which were dishonoured

17. Apply deposit in NetSuite:

18. Direct debit payments go to Undeposited Funds first
19. The school applies a deposit in NetSuite to move the funds from undeposited funds to the bank account
20. This completes the payment lifecycle

ABA File Format

The ABA (Australian Bankers' Association) file is a fixed-width text file with three record types:

Record Type	Code	Description
Header	0	File header — school's bank details, file description, processing date
Detail	1	Individual transaction — parent's bank details, amount, reference
Footer	7	File totals — record count, total debit amount, total credit amount

Important: ABA files must be generated with exact formatting (fixed column widths, specific field positions). Any formatting error will cause the bank to reject the entire file.

---

Credit Card vs Direct Debit Comparison

Aspect	Credit Card (eway)	Direct Debit (ABA)
Processing	Fully automated (API)	Semi-automated (file generation automated, upload/reconciliation manual)
Speed	Real-time response	Bank processing time (typically overnight)
Deposit	Direct — payment posts immediately	Via undeposited funds → deposit
Failure handling	Immediate decline code	Bank dishonour report (delayed)
Cost to school	Merchant fees	Bank direct debit fees
Parent setup	Card number via suitelet	BSB + Account number via suitelet

---

RPS Status Lifecycle

                ┌──────────┐
                │ Created  │
                └────┬─────┘
                     │
                     ▼
                ┌──────────┐
           ┌───▶│ Pending  │◀──── (if retry after failure)
           │    └────┬─────┘
           │         │
           │         ▼
           │    ┌──────────┐     ┌──────────┐
           │    │Processing│────▶│Processed │ (success)
           │    └────┬─────┘     └──────────┘
           │         │
           │         ▼
           │    ┌──────────┐
           └────│ Failed   │ (decline / dishonour)
                └──────────┘

    Separate actions:
                ┌──────────┐     ┌──────────┐
                │Cancelled │     │ Refunded │
                └──────────┘     └──────────┘

Status	Description
Created	RPS record created when parent submits payment details
Pending	Waiting for processing date
Processing	Currently being submitted to eway or included in ABA file
Processed	Payment successful — payment record created in NetSuite
Failed	Payment declined (eway) or dishonoured (bank)
Cancelled	Payment cancelled (e.g., parent withdrew, method changed)
Refunded	Payment was refunded after successful processing

---

Monitoring & Reporting

The school monitors payment processing through:

• Saved searches for RPS status by date, method, and status
• Outstanding payments dashboard — families with overdue/failed payments
• Collection rate reports — percentage of payments collected vs billed
• Failed payment reports — used to follow up with parents about declined cards or dishonoured direct debits

---

Related Documents

• ARM Billing Process
• Payment Method Change Procedure
• ARM Overview
• Meeting Extraction