PushCoin v3: Minimizing customer-related information

Why we are simplifying profiles

PushCoin v3 focuses on what is essential for transactions and ledger integrity. By limiting the data we require about customers (students, parents, or staff), we reduce onboarding friction, simplify integrations, and lower our compliance footprint. Schools can still enrich records, but the core platform only depends on a few essential fields such as a stable customer identifier and a nickname/full name to process purchases, refunds, issue receipts and produce reports.

What is required

  • customer_id – a unique and stable identifier your school assigns to a person.
  • full_name – In our system design, we are moving away from the rigid first/middle/last name convention and adopting a single full_name field. This change acknowledges the reality that naming conventions vary widely across cultures and cannot always be neatly divided into Western-style components. Many people have multiple family names, no middle name, or ordering traditions that don’t align with “first/last,” and forcing those patterns can result in inaccurate or awkward representations. By capturing a name exactly as the customer prefers to be known, we respect cultural diversity while reducing the complexity of data entry and storage.
  • nickname – To complement full_name, we are introducing a nickname field that serves as a flexible, user-friendly reference for everyday interactions. Whether it’s a shortened version of a name, an informal nickname, or the preferred way a customer wishes to be addressed, this field provides the practical equivalent of a “first name” without imposing structural constraints. It ensures our interfaces, receipts, and communications can remain personal and approachable while keeping full_name intact for formal or legal use.

We are also introducing two merchant-defined fields, labels and tags, to give schools more flexibility in categorizing and identifying their customers. Labels are simple, space-free strings such as STUDENT or STAFF that make it easy to group and recognize individuals at a glance. Tags, on the other hand, are key–value pairs like “IS_STUDENT”: TRUE that provide richer context and can be leveraged in reports, searches, and filters. Together, labels and tags allow merchants to adapt the system to their unique organizational needs without complicating the core customer record, making the platform more powerful and customizable.

To replace rigid “primary/secondary contact” fields, we’re introducing flexible relationships: optional records that describe how other people (e.g., parents/guardians) relate to a customer (student). A relationship captures the related party’s contact info, their role (Parent, Guardian, Caregiver, etc.), and verification status. This allows us to link customers into households (“families”), support real-world structures like blended or multi-guardian families, and “bubble up” important events—receipts, low-balance alerts, invitations—to the right contacts without duplicating data or hard-coding assumptions.

Relationships can be provided by schools or created dynamically by families. When a school seeds relationships, the platform can email time-limited secret codes to those contacts; parents use the code to verify and link their own accounts to the student. This design gives fine-grained control (per-relationship permissions), supports many-to-many links (one parent, multiple students; one student, multiple guardians), and simplifies lifecycle actions like revoking access, updating roles, or auditing communication history—all while keeping the student’s core record clean and privacy-aware.

Relationships play a significant operational role beyond just communication. They allow schools to properly assign benefits such as NSLP eligibility to the right students, manage invoicing in cases where multiple guardians share financial responsibility, and support split payments across households. By explicitly modeling these connections, the system can align financial, regulatory, and communication workflows with the real-life structure of families, ensuring both accuracy and flexibility in day-to-day operations.

What becomes optional

Bottom line: everything else. Any additional attributes—such as the examples below—are entirely optional. When you provide them, we store them as tags that stay attached to the customer but do not drive built-in business logic.

  • Customer type (parent, student, staff, guardian, etc.)
  • Grade
  • Gender
  • Homeroom
  • Position or title
  • Date of birth
  • Allergies
  • Phone numbers, addresses, other contact data

Because these values live in merchant-managed tags, you can decide which fields matter for your operations or omit them entirely.

Working with Tags and Labels

  • Creating tags: You supply key/value pairs when creating or updating a customer record. We persist them exactly as provided.
  • Updating tags: Send a new set of tags whenever something changes; we overwrite the previous set.
  • Reporting: Tags flow through to exports and APIs so you can filter or group results in your own analytics tools.
  • Tag names are restricted to upper-case alphanumeric-characters, underscores (_), and dashes (-) to keep them simple, consistent, and compatible across systems. This avoids issues with spaces, punctuation, or special symbols that could complicate reporting, filtering, or API usage.
  • Tag values can contain arbitrary (UTF-8) characters and have a limit of 10,240 bytes.
  • Labels are restricted to upper-case alphanumeric-characters, underscores (_), and dashes (-), similar to tag names.
  1. Maintain a single stable customer_id for each person.
  2. Use tags and labels for any descriptive data you care about locally (grade levels, homerooms, parent/student flags, etc.).
  3. Keep tags and labels to minimum — this keeps records clean without affecting system behavior.
  4. Keep sensitive data (e.g., medical information) out of tags unless your policies explicitly allow it; PushCoin treats tags as standard profile metadata.

Benefits

  • Simpler onboarding: Fewer mandatory fields mean faster imports and less data cleanup.
  • Flexible customization: Schools decide which descriptors matter without waiting for platform schema updates.
  • Easier compliance: Minimal required data reduces exposure when handling privacy or retention requests.

If you have questions about migrating existing customer profiles or mapping current data into tags, contact PushCoin support team. We are happy to review exports or provide templates tailored to your SIS or HR systems.