Description
Summary We are implementing a payment architecture for an Australian vocational education business processing a high volume of enrolments with deposits and instalment plans on Zoho CRM, Zoho Books, Stripe and n8n. The system is fully designed. You receive a complete specification: field definitions, a custom CRM module spec, event maps, six n8n workflow definitions, and a 15-case UAT matrix. Your job is to build exactly what is specified, under our direction, and prove it works. What the system does Every sale becomes a Zoho Books invoice; deposits are paid by card link, bank transfer or PayID Every unpaid balance is collected by a Stripe subscription schedule (card or BECS direct debit) set up through one hosted mandate session A custom CRM module (Payment Ledger) keeps every deposit and instalment permanently in one of four states: Invoiced, Paid, Overdue or Outstanding, updated only by automation Deal pages show an all-paid indicator, outstanding and overdue roll-ups and warning banners; a nightly job reconciles Stripe vs CRM vs Books and alerts on any variance What you will build Zoho CRM: one custom module, roll-up fields, a Canvas banner, two Deluge buttons with validation, Blueprint changes, field-level security Zoho Books: webhooks (invoice paid and overdue), API invoice creation and payment recording, verification of the existing Stripe gateway link on invoices Stripe: setup-mode Checkout (card plus BECS), subscription schedule creation and amendment via API, signed webhooks, retry configuration n8n: six workflows with an idempotency store and error queue, all credentials under client-owned service accounts Testing: run the 15-case UAT matrix in Stripe test mode against a Books test organisation; two weeks hypercare after go-live Must have. Your proposal should evidence all of these together, not separately: Zoho CRM custom modules, Deluge and Blueprints shipped to production Zoho Books API: creating invoices and recording payments programmatically Stripe API depth: subscription schedules, Checkout in payment and setup modes, webhook signature verification n8n in production. n8n is the client's platform; Make or Zapier substitutes will not be accepted Webhook reliability patterns: idempotency, deduplication, out-of-order handling, error queues Nice to have: Australian payments (BECS settlement timing, PayID, PayTo), BigQuery, the native Zoho Books to CRM sync, education sector experience. Acceptance: all 15 UAT cases passing, witnessed by us; go-live with zero reconciliation variance for five consecutive business days; workflow documentation plus one recorded handover session. Timeline and budget: the spec estimates 6 to 7 working days. Fixed price across three milestones: mobilisation 20%, UAT pass 60%, hypercare complete 20%. Process: shortlisted applicants receive the project brief, then sign an NDA for the full specification and client identity, then a 30-minute technical Q&A before final pricing. All work happens in test environments until UAT sign-off. Client-owned service accounts only; no personal tokens at any point. To apply: start your proposal with the word LEDGER so we know you read this. Then: (1) link one or two projects combining Zoho with a payment API, (2) answer briefly: how do you stop a Stripe webhook that arrives twice from double-recording a payment in Zoho Books, (3) confirm or challenge the 6 to 7 day estimate with reasoning. A considered challenge is viewed more favourably than an unexamined confirmation. Generic proposals and boilerplate will be declined without reply.