Specs

Security Basics specs

Setup notes and briefing numbers for Security Basics.

Verification points before publishing

Keep terms, risk notes, and customer-facing wording consistent across finance, ops, and support.

Security Basics specs is where a team records the exact checks that must appear in any note about Instant EFT, PayShap, or DebiCheck. Capture the payment rail, what proof is acceptable, and which screen or bank message must be seen before stock, access, or service moves forward. South African operating conditions matter here, especially load-shedding gaps, mobile banking screenshots, and handovers between finance, ops, and support.

Reference handling is part of the spec, not an afterthought. State where the payer reference is copied from, how it is stored, and which mismatch triggers a hold for review. Teams also need wording for customer-facing notes so they do not treat a pending message as settled funds.

Outputs used by finance and support

Use this spec to set one version of the truth across checkout text, internal checklists, and support replies. It should name the risk points for each method, such as sender-initiated Instant EFT proof, PayShap alias confusion, or DebiCheck mandate authentication status. Short, fixed wording reduces avoidable disputes when staff on different shifts explain the same event.

Link Security Basics specs to the matching rails note and any incident record before expanding the document. If a release depends on payment, the spec must say which bank-side status is required and what evidence is saved against the order reference. Use the contact form when a screenshot or checkout wording needs review against the current setup.

  • Accepted proof listed for each payment rail
  • Reference checks defined before fulfilment starts
  • Customer wording aligned with bank status terms

South African payment handling conditions

These specs need to reflect how South African teams actually receive and verify payments. A branch desk in Durban, a warehouse office near Johannesburg, and a support queue in Cape Town may all see the same transaction through different tools and at different times of day. The document should account for hand-captured references, proof shared on WhatsApp, and bank app screens shown across a counter.

Power cuts, patchy mobile data, and courier cut-off times change how strict the checks must be. PayShap can look immediate to a customer, while internal release rules may still require a separate confirmation step. DebiCheck notes should also separate mandate acceptance from later collection outcomes so teams do not blur two different events.

Operated by Astros Marketing (Pty) Ltd from 2 Makro Place, Sunnyrock 1401.

Inputs needed for this spec

Bring the current checkout wording, payment screenshots, exception cases, and any dispute examples tied to Instant EFT, PayShap, or DebiCheck. Include the exact labels shown to customers and the internal status names used by finance or ops. That material makes it possible to write checks that match the live process instead of a meeting-room version.

File updates when bank messages, release rules, or support wording changes. Keep the spec close to the related process note so staff can move from policy to action without guessing which version applies. Where approvals are required, name the owner for each check and the record that proves it was completed.

What our Real-Time Payments customers say

Verified Google reviews