Back to DevLog

Deep Diving into Production Data: Mapping Payment Acquirers Like a Detective

2 min read

Sometimes the best part of building stuff is when you finally get to peek under the hood of production data and see what's actually happening.

Today I connected to the AXP production database to dig into some transaction data. Nothing too fancy - just wanted to see how yesterday's paid transactions broke down by payment acquirer. You know, the usual "let's see what's really going on" kind of analysis.

The Detective Work

First challenge: figuring out the right table name. Turns out slssalestransaction (no underscore) doesn't exist - it's actually sls_sales_transaction. Classic database naming gotcha that probably trips up everyone at least once.

Second puzzle: the acquirer column stores integers, not readable names. Had to dig through my reference files to find the mapping between codes and actual company names. Kind of like decoding a secret message, but less exciting.

The Numbers

Here's what yesterday (March 26th) looked like for paid transactions:

  • TNG2 (TNGD): 27,836 transactions - clear winner
  • TNG (REVPAY): 22,289 transactions - strong second
  • CIMB: 16,876 transactions - solid third place
  • B-DuitNowQR (BOOST): 9,014 transactions
  • SPAY: 682 transactions
  • Boost (AXIATA): 274 transactions
  • And a few smaller players...

Total: 77,096 paid transactions in a single day. Not bad!

The Query That Did the Magic

SELECT acquirer, COUNT(*) AS count
FROM sls_sales_transaction
WHERE status_id = 11
  AND DATE(transaction_time) = CURDATE() - INTERVAL 1 DAY
GROUP BY acquirer
ORDER BY count DESC;

Nothing fancy, but it gets the job done. The key was using transaction_time for the date filter (not the other timestamp columns that didn't quite fit) and status_id = 11 to catch only the successfully paid transactions.

What's Next?

This was just a quick snapshot, but it opens up some interesting possibilities. I could easily extend this to look at different date ranges, add transaction amounts to see revenue patterns, or maybe track trends over time.

There's something satisfying about connecting directly to production data and just... exploring. No dashboards, no pre-built reports - just raw SQL and curiosity. Sometimes that's exactly what you need to understand what's really happening in your system.

Share this post