Skip to main content
The Business Customer Portal gives each organisation a separate operational view of its digital asset payment activity. It is designed for teams such as estate agencies, developers, professional services firms, payment businesses, exchanges, and treasury operators.
A white-labelled property-payment portal and separate customer sign-in exist for controlled demonstration. Production identity, tenant isolation, billing, data retention, and role-based access still require security validation before real client onboarding. The browser is not the authoritative policy or risk engine.

Open customer sign-in

Sign in to an organisation-specific controlled portal.

Open product gateway

Choose the appropriate payment protection workflow.

​
Controlled property-payment journey

  1. The business creates a customer or transaction record, such as a Dubai property reservation or deposit.
  2. The portal creates a branded payment request with the property, amount, asset, network, reference, and destination details.
  3. The business sends the secure link to the prospective buyer.
  4. The buyer connects a wallet and reviews the payment details before submitting the transaction.
  5. SafeReceive screens the source wallet and applies the business policy.
  6. The portal records the payment, ALLOW, REVIEW, or BLOCK outcome, evidence, and follow-up action against the business transaction.
  7. An authorised user may generate a comprehensive report when deeper review is required.
The Northstar Properties material is fictional demonstration data. It shows how white-labelled property workflows can operate without representing a real customer, property, payment, or approval.

​
Portal controls

​
Organisation separation

Each production customer must have its own organisation boundary, users, roles, policies, wallet allowlists, payment records, report records, branding, and audit history. Do not reuse demonstration credentials for a real customer. Production access must use approved identity controls, password protection, secure session handling, rate limiting, access revocation, and auditable administrative changes.

​
Security boundaries

  • Keep provider credentials and raw restricted data off the client.
  • Enforce tenant isolation and role-based access on the backend.
  • Record the actor, time, policy version, reason, and previous value for configuration changes.
  • Do not let a user-interface change overwrite historical decisions.
  • Redact or hash sensitive evidence when retention or licensing terms require it.
  • Never place treasury private keys, seed phrases, provider secrets, or unrestricted API keys in the portal.
  • Require a new protection check when a payment’s source, destination, network, token, amount, or policy changes.