

Fundraising tech/orphan slayer

From Wikitech-static
Revision as of 20:17, 15 November 2021 by imported>Damilare Adedoyin (→‎How does the Orphan slayer work?)
Jump to navigation Jump to search

What is the Pending Table?

The pending table is a SQL Database Table which exists in the Smashpig database. Basically, the Pending table holds information about transactions which have already begun but are yet to be completed on our servers. That is we were able to collect some data from the donor but for some reason we lost contact with them along the way and so the donation couldn’t be finalised on our end.

Removing data from the Pending Table on the Smashpig Database

In order to remove rows from the pending table, the following queue consumers are run every 3-4mins:

  1. The payment initial queue consumer would delete rows in the Pending table that correspond to rows in the fredge payment initial table with a status of “Rejected”. ??
  2. Donation queue consumer deletes items in the pending database with an existing order ID in the donations table. This is done in order to leave only ongoing transactions with undetermined final status in the pending table.

What transaction is considered an orphan?

A transaction is considered an orphan if it exists in the pending table with a "PENDING-POKE" status.

What is the OrphanSlayer?

The orphan slayer is a Drupal module that basically reinitialises SmashPig on the orphan transactions described above. It works on transactions that are in the PENDING-POKE status. Transactions in the PENDING-POKE status are basically transactions that made it to the gateways but for some reason weren’t able to return back to our servers for the final steps. The overall goal of the orphan slayer is to remove orphan transactions from the Pending table of the SmashPig database.

How does the Orphan slayer work?

The following steps are taken in the OrphanSlayer module in order to remove orphan transactions from the Pending table of the smashpig database:

  1. Get the oldest transaction from a particular gateway (for ex. Ingenico, Paypal) in the Pending table.
  2. In order not to perform the rectification operation on the transactions hastily, there exists a loop that checks to ensure the oldest transaction is above 30mins old. At that age, it's safe to assume that something occurred that prevented the action from being completed.
  3. The “Contribution tracking ID” is a unique ID assigned to a donation in the pending queue. If the selected transaction has a “Contribution tracking ID”, the method goes ahead to rectify the transaction. Else, the transaction is cancelled.
  4. In order to rectify an orphaned transaction, the gateway adapter would be reinitialized using information from the transaction.
  5. The “Contribution ID” is the unique ID assigned to a completed donation transaction. Hence, a donation in the pending table with a “contribution_id” value would imply that the transaction has been completed and as such wouldn’t need to be rectified.
  6. The rectification process depends on the gateway selected due to the different implementation of the “processDonorReturn” method across the gateway adapter. The “processDonorReturn” method ideally should be run immediately after the donor makes payment on the gateway and is redirected to our servers for final steps. Hence in order to get orphaned transactions to the final status, the “processDonorReturn” method would have to be reinitialised on the transaction. For ingenico, the procedure followed in the “processDonorReturn” method are as follows:
    1. Get the pending transaction order status from payment processor
    2. Perform action for ‘Confirm_CreditCard’ transaction
    3. Initiate stopwatch for the transaction logging
    4. Get our server’s validation action to determine if the transaction needs to be captured.
    5. Transaction is either cancelled or captured depending on the order status and the validation action result.
    6. Stopwatch is stopped and transaction process time is logged.
  7. If rectification is successful or process is cancelled the corresponding row on the Pending table is deleted, if the payment was captured the message is pushed to the donation table.