Development Story of the OK Cashbag Welfare Points Service: Security, Large-Scale Processing, and Realistic Choices

OK Cashbag Welfare Points is a service that manages welfare points issued by partner companies to their employees, providing card issuance based on Hana Card, simple payment registration, income deduction benefits, OK Cashbag promotions, and Oky Club benefits together. By default, payments could only be made in allowed industries, but if combined use with OK Cashbag points was set, it was possible to bypass the industry restriction when paying.

The configuration was divided into a core system, the OK Cashbag app, and the admin console. The core system handled partnership contracts, card status, merchant contracts, allowed industries, real-time payment processing, and point accrual/use/inquiry; the app provided card registration and user functions; and the admin console handled employee management and point issuance/deduction.

Card registration was done in the app after going through ID verification and account verification, and the registration information was then passed to the core and admin systems. The admin console could register employee information alone in advance, but since actual points could only be used after card registration, the structure was such that assignment/deduction requests before that point were only stored, not executed.

The user app provided the following features.

• Welfare points inquiry and usage history inquiry
• Simple payment registration and subsequent settings changes
• Welfare card status change when a card is lost
• OK Cashbag combined use setting
• Payment password change for online use
• Receipt approval request, used when a payment in an allowed industry was made with cash or another card

For receipt approval requests, the system needed to accurately read the approval number, merchant name, and business registration number from the attached image, and for this, an OpenAI-based receipt recognition feature was introduced. Comparison results showed that GPT-4o had a long response time and high cost, and had recognition errors for the approval number in some requests; GPT-4.1-mini succeeded all 3 times and had the best balance of response time and cost. On the other hand, GPT-4.1-nano repeatedly had recognition errors for payment date, transaction amount, and card issuer. In the end, considering recognition accuracy, response time, and cost together, gpt-4.1-mini was adopted.

Admin security was the first problem that had to be solved. Because it was a financial-natured service, it was subject to security review from the legal review stage, and the master administrator and partner company administrators had similar functions but different access control requirements. Ideally, they would have been separated into different code and servers, but due to lack of schedule and manpower, the team chose a realistic solution of separating access paths within a single codebase.

The security structure was organized as follows.

• Master administrator: private domain, mandatory VDI, fixed IP, firewall policy applied, ID/PW and permission check
• Partner company administrator: public domain, direct internet access, 2FA, mobile OTP, access control by partner company ID unit

Thanks to this structure, the master administrator secured strong security at the level of a closed network, and while the partner company administrator could not use the internal permission system, this was compensated for with secondary authentication and data-level blocking. Activity logs were also periodically collected and attached to a monitoring system.

For large-scale processing, requests and execution were separated. Requests that generated hundreds to thousands of items at once, such as company-wide employee registration or point issuance to all targets, were first saved to the DB and simultaneously put into a Redis Queue for an immediate response. The Worker polled the queue to retrieve tasks, and for example, split a request to issue 1,000,000 points to 700 people into 700 individual tasks, saving and processing them again.

Actual issuance/deduction was performed in 10-minute batches, and the success/failure of each task was aggregated and reflected in the initial request data. Operators could check progress and the number of remaining tasks, and this structure secured both responsiveness and stability.

The schedule was another constraint. The welfare points service had to launch within the year for the beginning-of-year allocation, and development started in early September. Originally, it would have been ideal for the core system to provide point assignment/deduction history, card usage history, and receipt processing history via API, but there wasn't enough time to newly define the API and finish development, testing, and stabilization.

So the direction was changed to DB-based data integration. After consultation with the DBA, it was possible to integrate the 6 core tables needed via OGG (Oracle GoldenGate), which secured the possibility of implementation and launch within the schedule. The judgment was that building a system that actually works within the given constraints was more important than a perfect architecture.

In the end, this project is summarized as a case that directly addressed three constraints—security, large-scale processing, and a tight schedule—each head-on, and chose the most executable design between ideals and reality.