Basic Assignments
 
Options & Settings
 
Main Time Information
Color Code: Blue
Assigned To: Bryan Dayton
Created By: Bryan Dayton
Created Date/Time: 8/5/2021 11:14 am
 
Action Status: Blank (new)
Show On The Web: Yes - (public)
Priority: 0
 
Time Id: 8102
Template/Type: Brandon Time
Title/Caption: check and push code
Start Date/Time: 8/12/2021 3:00 pm
End Date/Time: 8/12/2021 4:00 pm
Main Status: Active

Sorry, no photos available for this element of time.


Uploaded Media/Content & Other Files (1)
Media Name   File Type Date Description
voiding_credit_card_transactions_bryan_and_brandon.mp4   Video 8/14/2021 This is a small recording of Bryan and I going over some code and processes for voiding credit card transactions, looping over possible multiple transactions, and voiding invoices. We also went over refunds and the difference between voids and refunds a bit in the video. 20 minutes.


Notes:

Bryan and I met up to go over a project that he is working on. For one of his projects, he is working on some credit card and EMV chip reader actions and functions. He had some questions on doing voids and the difference between voids and refunds. There is a slight difference. To void a credit card transaction, it can't be batched or settled (on the gateway side of things - it still needs to be non batched or pending settlement). A refund requires a new, negative invoice to reverse the process. Ideally in a refund, you have the original invoice number and transaction id or reference number to relate back to the gateway where the refund is happening. Bryan asked me to record some of it. See attached if you want to see some of what we were talking about. Not the world's most exciting stuff, but part of the project.

Some other insight from the meeting. This is more for me and notes on the value of good project management.

- Missing a scope of work. The original project started and then the client changes his mind and the developer started on the new project. That doesn't happen very often. No scope of work was every set in stone for the new project. It was just kind of - get this done. What does done mean. During our meeting, we discovered that there were tons of possible options, many deeper than other that weren't required but felt like they could be part of the project. Imagine a checklist of 30+ options that a payment gateway could possibly do. We only needed 4 or 5 of them but because they existed, the developer was starting to go down that path - and some of the functionality was deep and complex.

- Communication - the developer was expressing that no one was answering his questions. He was sending emails to the group, but no body was responding. It may be that no one knew who was the main contact and who was supposed to do what. I know that I do that, if I'm part of a big group email, I may read it, but if it's not my area or I'm not the main contact, I don't usually answer back unless I need to. Having a single point of contact is ideal. You can copy other people in to the thread, but point the email at a single contact if a response is needed. Once again, this is the ideal.

- Last of all, I honestly didn't even know that any of this was going on until we had the meeting. Pretty scary. We are trying to help and mange the projects that we have in front of us, but sometimes we don't really know what is going on. More lessons learned.