Contents
- Overview
- Setup - Step 1: Account creation
- Setup - Step 2: Merchant connection
- Setup - Step 3: Terminal connection
- Processing - Repair Order UI
- Processing - Taking and receiving payment
- Processing - Error response management
- Processing - Refunds/Voids
- Reporting - Program User Interface
Overview
This document describes the integration between the program's point-of-sales application and 360 Payments payment processing technology. The purpose of this document is to illustrate the end-to-end functionality, the user experience, and reporting features.
The integration includes 3 primary components:
- Account and terminal setup by location
- The user interaction required in the program interface to send a payment amount to a payment processing terminal
- The reporting and data captured, stored, and sent for each transaction.
Setup - Step 1: Account creation
- An existing repair shop subscribed to the program contacts 360 Payments to create an account:
- https://get.360payments.com/
- If you already have an account, contact your account rep about next steps.
- 360 Payments creates an account
- Terminals are configured by 360 Payments according to their Serial Number.
- Serial Number is printed on a sticker on the back of the terminal device as “SN”
- 360 Payments sends the pre-configured terminals to the repair shop location.
- A staff member will submit shop contact info and Serial Number(s) via our software'sinterface (details in Step 2, below) to make the connection and begin processing payments.
Setup - Step 2: Merchant connection
- Go to User Icon ⟶ Shop Settings ⟶ Merchant
- Under 360 Payments Setup, click the “Activate” button:
- Staff member is presented with company information setup/confirmation modal:
- All fields are required
- All fields are required
- Staff submits modal (click “Activate 360 Payments”)
- Modal will close and 360 Payments Connection will show as “Connected” and the “+ New Terminal” button appears to connect terminals
- NOTE: If the shop already configured an account with 360 Payments and have been issued terminals, they can configure those terminals immediately.
- If the shop has not created an account with 360 Payments separately, or they have yet to receive terminals, they will need to wait to add terminals at this time.
Setup - Step 3: Terminal connection
- Staff clicks button to add a new terminal
- Staff is presented with Terminal setup modal
- Staff enters Terminal “name” (to identify and select it from the RO page) – required
- Staff enters Serial Number – required
- Staff submits modal (“PairTerminal”)
- Modal will not close (submission pending) while terminal connection is confirmed
- Program backend confirms terminal connection via 360 Payments
- Failure or timeouts will trigger an error message, not allowing you to proceed
- Successful connection closes the modal
- Configured terminal appears in shop settings page table
- Name
- Serial Number
- Staff can add additional terminals (same workflow)
- Staff cannot currently remove a terminal or edit its name; this functionality is forthcoming.
Processing - Repair Order UI
- On the Repair Order, once at least one terminal is configured on the Merchant settings page, a “Terminal” option will present in payment method drop down.
- “Terminal” payment method is selected by default
- When “Terminal” is selected, “Post Payment” button is replaced by “Send to Terminal” button.
If only one terminal is configured, that terminal is automatically selected in the drop down
- When “Terminal” is selected, “Post Payment” button is replaced by “Send to Terminal” button.
- If more than one terminal is configured, when a staff member first views a Repair Order (and they have permission to view payment box), no terminal will be pre-selected
- “Send to Terminal” button inactive until target terminal is selected
- “Send to Terminal” button inactive until target terminal is selected
- Once a staff member selects and uses a terminal, that terminal will be selected by default on the next RO (until a different one is selected).
- In other words, staff member’s default terminal will always update to the last one used, for convenience
- In other words, staff member’s default terminal will always update to the last one used, for convenience
Processing - Taking and receiving payment
- Given a staff on a repair order, when they view the Payment box at the bottom of the page:
- Selected payment method selected = Terminal
- Terminal selected = one of terminals configured on shop settings
- Payment amount entered
- When a staff member clicks “Send to Terminal” button
- Button indicates in progress connection being made to terminal
- Button indicates in progress connection being made to terminal
- Program backend lights up terminal via 360 Payments
- Amount entered in Payment box on the program now appears on Terminal to process
- Staff member swipes/dips card on terminal device
- Transaction is processed
- Connection between terminal and 360 Payments
- Management of timeouts/errors on device handled by 360 Payments
- Success/decline/error sent to the program via response from 360 Payments
- Button appearance will reset to “Send to Terminal” upon page refresh/reload or is opened elsewhere
- This will not affect the transaction job (running in the background)
- This will not affect the transaction job (running in the background)
- If success, and webpage session has not been interrupted, the program updates RO dynamically with posted payment
- If payment is processed after interruption, refreshing the page will show the results of the transaction.
- If payment is processed after interruption, refreshing the page will show the results of the transaction.
- When payment is posted:
- Payment details post in Grand Total box, under grand total
- Date and time
- Payment method = “Credit Card via Terminal”
- Payment amount
- Card information (varies depending on card type)
- Name on card
- Transaction ID
- Any PDF of invoice, created at the time of payment or thereafter, will include the same payment details as shown on webpage
- Payment details post in Grand Total box, under grand total
- All payment transactions post to the Job Log.
- Additional messages handle cases when payment returned is less than payment sent because of partial authorization on card via terminal
- If declined, the software RO surfaces message
- “Waiting for Terminal” button UI returns to “Send to Terminal”, no spinner
- Message appears in box regarding payment failure
- No payment is posted, no change is made to Grand Total box
- No invoice is emailed (if checkbox is checked).
Processing - Error response from Terminal
- If the terminal has an error, a transaction is cancelled, or the 360 Payments connection fails to respond:
- “Waiting for Terminal” button UI returns to “Send to Terminal”, spinner icon/gif goes away
- Message alerts regarding connection error
- Different errors available depending on 360 Payments scenarios
- Different errors available depending on 360 Payments scenarios
- No payment is posted, no change is made to Grand Total box
- “Waiting for Terminal” button UI returns to “Send to Terminal”, spinner icon/gif goes away
Processing - Refunds
- Ability to refund or void transactions can be found in Security permissions for each staff member as “Refund customer payments
- When a staff member with permission to refund transactions views RO with at least one existing terminal transaction:
- Link to “Refund this transaction” appears under Terminal recorded transactions
- Staff without permission do not see these links
- When staff member clicks “Refund Transaction”
- Confirmation modal appears
- Refunds occur after a terminal batch has been closed
- Voids occur before a terminal batch has been closed
- Confirmation modal appears
360 Payments will handle the transaction as a Refund or Void depending on the status of the batch
Refund or Void can only be exact amount of previously processed and confirmed transaction via terminal, directly back to the same card
- When the modal is submitted, refund/void request is submitted to 360 Payments
- Modal remains open with spinny gif until confirmation is returned
- Timeouts/errors surface notification in modal; spinny gif UI goes away; button restores to “Refund/Void Transaction” action to try again as needed
- Same rules to control against duplication as when RO page is closed or refreshed
- When refund/void is successfully returned from 360 Payments, modal closes and refund/void details post to Grand Totals box
- Resulting Balance Due calculated and shown
- Staff may post another payment as usual
- Staff may post another payment as usual
- The RO Log will show Refund/Void details
Reporting - User Interface
- Payments processed through a 360 Payments terminal appear in their own batch on the Invoices page, under “Credit Card via Terminal (360 Payments)”
- This is the same area as all other RO payments:
- Staff with permission to view exports may export Customer Payments
- Payments processed through a terminal appear with “Credit Card via Terminal (360 Payments)” in the Payment Type column
- Refunds and voids appear as negative payment amounts
- terminal nickname and ID present on payment transactions (not refunds or voids) to cross-reference device batch details.