Price: 0
Number of applications: 5
23.06.26 (inclusive)
It's being negotiated
Idea
ICT tasks
Medicine
Other technological solutions
Software/ IS
Processing non-cash payments in clinics that do not have direct API integration with banks creates huge operational risks.: Financial fraud and the human factor: Cashiers are forced to manually enter account amounts into Kaspi's physical terminals. Errors in zeros (hitting 5,000 instead of 50,000) lead to direct financial losses . Patients can show cashiers fake screenshots or fake transfer applications, deceiving the registry. Queues due to manual synchronization: After the payment has been completed at the bank terminal, the cashier needs to manually find the patient's card in the IIA (or Excel spreadsheet) and mark this invoice as paid . This is a double job, because of which the service time for one patient at the checkout can reach 3-5 minutes, creating annoying queues. Chaos in mixed payments: When a patient pays in different ways, in the old systems it is impossible to split one check into parts. Cashiers have to create two different accounts or keep records "in a notebook", which eventually leads to huge discrepancies in the Z-reports when the shift is closed.
The launch of the fintech integration module with Kaspi Ecosystem will bring the clinic's payment acceptance process to the Enterprise level: 100% fraud protection: The strict cryptographic verification of Kaspi Webhooks signatures (HMAC-SHA256) will make it technically impossible to fake payment statuses. The cashier's interface will be updated only when the money is physically credited to the clinic's account . Full automation and speed: The target time for receiving the Kaspi QR code will be from 1.5 to 3 seconds. After paying on the patient's side, the DCH system atomically changes the statuses of transactions and accounts without the cashier's involvement at all, radically reducing the patient's billing time to a few seconds. Mathematically accurate convergence of the cash register: The architecture of mixed payment (SUM(transaction.amount) = invoice.total_amount) and automatic registration of payment methods will permanently eliminate discrepancies when summarizing and reconciling Z-reports at the end of the working day
Amina Agzamova
Purpose and description of task (project)
Create a secure, high-speed and fully automated gateway for accepting non-cash payments from patients. The main task of this block is to seamlessly integrate the Kaspi Pay API into the DCH cash register interface, eliminate manual entry of amounts at physical terminals, automate receipt of payment statuses (via Webhooks and Polling) and implement complex "mixed payment" mechanics, guaranteeing cryptographic transaction protection. Detailed description of the functionality and technical solutions: Deep integration with Kaspi Pay API (QR payments): Development of dynamic QR code generation mechanics. When choosing the "Kaspi QR" payment method, the DCH backend makes a POST/api/v2/payments/kaspi/qr request to the external Kaspi API, transmitting the exact amount and a unique invoice_id . In response, the server returns a graphical QR code (base64 PNG) and payment_id, which are instantly displayed on the cashier's screen . The waiting time for payment using the generated QR code is 15 minutes . A dual status tracking system (Polling + Webhooks): A fail-safe bundle is being implemented to ensure payment confirmation. The client part (POS screen) starts polling: it sends GET/api/v2/payments/:payment_id/status requests every 3 seconds . In parallel, the DCH backend configures a secure endpoint POST /api/v2/webhooks/kaspi to receive asynchronous notifications (Webhooks) from Kaspi servers about a change in payment status . Cryptographic transaction Protection: This is a critical security element. Any incoming webhook from Kaspi is subject to mandatory verification. The system calculates the HMAC-SHA256 hash(body, kaspi_webhook_secret) and checks it against the signature from the header . Requests without a valid signature are instantly rejected with an HTTP 401 error, which makes it impossible for attackers to substitute the payment status . With the PAID status, the system atomically updates the transaction, changes the account status, and publishes the WebSocket event payment.completed for the interface . Mechanics of Kaspi Installments: Implementation of the POST /api/v2/payments/kaspi/installation endpoint to integrate the option of choosing the installment period (3, 6 or 12 months) directly from the DCH POS terminal . The bank approves the loan asynchronously, and the status in DCH is updated via a webhook . Mixed Payments: Implementation of complex business logic for cases when the patient wants to pay one bill in different ways (for example, 30,000 tenge in cash and 20,000 tenge via Kaspi QR) . The interface provides two input fields. The server creates two different transactions (using the cash and kaspi_qr methods) linked to the same account, and performs strict mathematical validation: SUM(transaction.amount) = invoice.total_amount (accurate to 1 tenge) . Bank Cards and PCI DSS: DCH does not store or transfer bank card data, leaving the physical processing to POS terminals (ensuring PCI DSS compliance) . The cashier clicks the "Payment completed" button after confirmation at the physical bank terminal, and DCH records this method in the system.
Whatsapp
