Below you'll find some of the most common requests that come through on a weekend shift, and how to handle them.
Video clips will be made available on the Peach Academy.
Absa Escalation
https://support.peachpayments.com/a/solutions/articles/47001232486
1. Proof Of Refund:
Action: send the proof of refund to the merchant.
Navigate to the Peach Console -> Transactions -> Search for the merchant in the "Search for Merchants" search bar -> Search for the refund transactions in the "Search" search bar, using the transaction ID provided by the merchant:
If the merchant fails to provide the transaction ID, you should request it, or other transaction indicator values like the date and amount of the transaction.
These other transaction identifiers can be used to filter for the transaction in the filter search function.
Once the transaction is located, click on it and download the proof of refund by clicking the button in the top right hand corner:
Attach the downloaded proof of refund PDF to the ticket and send out the response.
2. Account Cancellation:
If a request comes in from a merchant to cancel their agreement with Peach Payments, you will need to assign this to the team member in charge of cancellations. Currently, this is Kayla Pretorius.
Simply assign it to the team member in charge of cancellations for them to action on Monday:
3. Existing User Password Reset
When a request comes from a merchant to reset their user access password to one of our dashboards, the first step is to confirm which dashboard they are trying to access, and whether they are trying to access the LIVE or TEST version of the
You can use the following template to request this information:
"Hi There,
Are you attempting to access the LIVE or TEST dashboard?
Please can you confirm which peach dashboard you are trying to access:
- Peach Console - https://console.peachpayments.com/
- BIP - https://peachpayments.ctpe.info/
- Paysafe dashboard - https://ppay.io
Thank you!"
Once this is confirmed you should:
For the Console:
Navigate to Users -> Search the user with their email (username) -> Click on the user -> Edit -> Reset Password:
For the BIP & Paysafe:
Navigate to Administration -> Contacts -> Navigate to the Merchant Level of the merchant profile -> Available Contacts -> Click the reset password button:
Once this is actioned, reply to the ticket with the appropriate 'reset password' canned response (there are ones for Console, BIP, and Paysafe).
4. Adding a New User:
The first step is the same as before - you need to confirm which dashboard you need to add the new user to, and whether this is for the LIVE or TEST environment. Use the same template as before.
Ask the merchant to clarify the required name, email, and user access level.
Once this is confirmed you should:
For the Console:
Navigate to the Merchant Profile -> Team -> Add User -> create the new user with the details the merchant supplied (name, email, access level):
For the BIP & Paysafe:
Navigate to the merchant profile level -> Administration -> Contacts -> Available Contacts -> create the new user with the details the merchant supplied (name, email, access level) -> Attach the profile to the "Attached Contacts" section -> send out the temporary password:
Once this is actioned, reply to the ticket with the appropriate 'new user' canned response (there are ones for Console, BIP, and Paysafe).
5. Transaction Status Confirmation:
If a merchant requests a confirmation on the status of a transaction attempt on their site, you will need to ensure that you have either the UID, the Transaction ID, or the Amount & Date of the transaction in order to search it up on the Console or the BIP.
The BIP will only show card transactions, but it does have better insights as to why a transaction failed (if it did). For all other payment methods, you'll need to search the Console.
If it is successful on our system, you may confirm to the merchant that the transaction is good.
If the merchant is querying a failed transaction but believes it to be successful (with proof of payment in the form of a bank statement provided by the customer), then you will need to query this failed transaction with the relevant acquiring bank.
If it is an ABSA ISO or Aggregation merchant, you will need to query the transaction to [email protected]
If it is a Nedbank ISO merchant, you will need to query the transaction with [email protected]
There are relevant canned responses for each acquiring bank query, that include a list of the information you will need to include for the bank to find the transaction on their system and confirm its status to you.
Once this part is actioned, ensure that you respond to the merchant to say that we are investigating the transaction with the bank and that we will revert back to them ASAP with feedback.
6. Error on Payment Gateway:
If a merchant sends in a ticket querying why they are seeing an error on checkout for their site, it could be any number of things.
This sort of investigation should be handled by an Applications Engineer.
The best thing to do here would be to revert back to the merchant on the ticket and gather as much of the following information for an Applications Engineer to have a look as soon as they are next online:
- Ask for a screenshot of the error that the merchant / customers are seeing
- Find out if the error is occurring in the LIVE or the TEST environment
- Find out what integration the merchant has implemented with Peach - ie, Copy & Pay; Server to Server; One of the plugins; etc
- IF it is a direct custom integration (CnP; S2S; MSDK; etc), ask the merchant to provide the credentials that they are using in their API calls - ie, the Entity ID & Access Token. You should also ask for the endpoint that they are POSTing to, and the response they are seeing.
- IF the merchant is using one of our plugins (Shopify; Wix; Woocommerce; etc) ask them to provide a screenshot of their plugin set up so that the Application Engineer that picks it up can compare their setup and credentials they are using to what we have on our system.
Once the above has been sent back to the merchant:
- If it is a Saturday, leave it unassigned, as the next person on shift on Sunday will likely be an Applications Engineer who will be able to assist.
- If it is a Sunday, assign the ticket to the Applications Engineer group, where the system will auto-assign it to one of the App Engineers.