There are many possible workflows depending on your specific system you are integrating that data into, as well as specific use cases.
Below, we suggest a workflow. Feel free to use it, or adapt it to meet your specific needs.
- At xx:30 every hour, grab the previous hour's data. This data is reliable but not yet reconciled. We recommend to keep track of the reconciliations (and discrepancies) too, if your data structure can accomodate that. An alternative to this would be to receive near-real-time webhooks (an HTTP request sent to a URL of your choice), with the transaction data for each processed transaction. This approach is chatty, so if you have many transactions, it will result in many HTTP requests to your URL. It is asynchronous, so it won't delay or harm a transaction in any way.
- At 08:00 every day, grab the previous 2 day's data. By now, most of this data is probably reconciled (we grab 2 days to check for any stragglers). There will be overlap, so be prepared to handle it (since on Monday you grab Saturday and Sunday's transactions, and on Tuesday you grab Sunday and Monday's transactions). Look especially for any discrepancies.
- At 08:00 every day, grab the previous week's discrepancies. There should be very few discrepancies, and every payment method that we are capable of reconciling
should already be reconciled, with discrepancies identified. The way to limit the export to those that have discrepancies is by using the
arguments. There are a couple kinds of discrepancies (currency/amount and result). An amount discrepancy may occur if someone uses another system to partially refund a transaction. A result discrepancy is most typical in case of a communication failure (however, there are also possible unknown conditions which may evoke a similar error). Each discrepancy shall be analyzed by Rebilly to try to identify the root cause.
Handling overlap / duplicate data
Since various downstream processors allow us to reconcile on different schedules, we suggested step 2 above with an overlapping workflow. Our system has an "id" which is a unique value per transaction. This "id" can help you identify if you should update or insert a record in your own systems.
Most discrepancy cases happen when a transaction was marked as declined (or similar such as canceled or abandoned) but is actually approved. In this case, it is recommended that you fulfill the customer's order (in some cases it may be recommended to void the order -- for example, if a subsequent duplicate order was placed). It likely depends on your business type. Discrepancies should account for well under 1% of transactions. Almost all of the discrepancies are false declines, not false approvals.