Payments and Transaction Flow

The OPS-COM system utilizes a standardized three-step transaction flow to manage the lifecycle of user purchases, such as parking permits. Understanding this workflow helps administrators accurately track financial commitments and manage inventory status from the initial reservation to final payment. This guide is intended for OPS-COM administrators responsible for financial processing and user account management.

Setup and Configuration

The payment transaction flow is aan 3inherent stepsystem process,process whichwithin includes:OPS-COM and does not require specific module configuration to function. However, administrators should ensure their payment methods and gateways are correctly configured before users attempt to make purchases.

Using

User/Adminthis linkFeature

The lifecycle of an item topurchase userconsists

1. Userof makesthree primary stages: linking the item, making a payment promise
promise,
2. Adminand processesprocessing payment
the

payment.

Step #1:

1: Linking the Item to a User

A user or an administrator links an item, such as a permitpermit, to thea user.user's Ataccount.

this

point,
• there is no payment link and the

  The item is "placed in an Awaiting Payment" sincestatus the user has not selectedbecause a payment method (madehas not yet been selected.

• The specific item is temporarily reserved and is no longer accessible to other users in the system.

The system utilizes an automated midnight clearing list. If a user reserves an item but does not proceed to the next step to establish a promise of payment).payment, As well, items (permits) are not accessible to any otherthe system user. There is a midnight clearing list which canwill automatically release permitsthe linkedpermit toback usersinto thatthe doavailable notinventory haveat promises for payment.midnight.

Step #2:

2: Making a Promise of Payment

UserThe user or adminadministrator linksselects a specific payment type (ie.e.g., cash, cheque, cash,or etc.)payroll Thisdeduction) putsto finalize the userreservation.

on

• This action constitutes a "promise to pay."

• The user's transaction is automatically added to the  Unprocessed Payments list,list.

  and
that
• list needs to be checked regularly.

  This allowsstep aprovides userusers the flexibility to mail in a cheque or visit the parking office in person to stopfinalize their transaction at a later time.

Step 3: Processing the Payment

Once the physical payment (cash, cheque, etc.) is received by the officeoffice, tothe makeadministrator payment.must Infinalize thesethe cases, a user has "promised" to pay. We suggest that permits be released (Drop Payment) after 2 weeks since that offers users enough time to make payment.

Step #3: 

Once payment is received (cheque is receivedtransaction in the mail,system.

or

• Access the userUnprocessed stopsPayments bylist.

• Mark the office to make a payment)  thespecific transaction is marked as processed.

  and
the
• user

  The item is now fully linked to the item.user's Ataccount, this point,and the itemfinancial transaction is markedcomplete.

  processed

---

Best Practices and isConsiderations

actually

(completely)
• linked

  Monitor Unprocessed Payments: Regularly check the Unprocessed Payments list to theensure user.pending transactions are finalized in a timely manner.

• Manage Inventory: Organizations should develop a business rule to drop payments and release permits after a set period, such as two weeks. This ensures that valuable inventory is not tied up indefinitely by unfulfilled payment promises.