SiKurban: A Web-Based One-Time-Use QR Code System Using LCG for Real-Time Duplicate-Claim Prevention in Qurban Meat Distribution

1. Introduction

Qurban (ritual animal sacrifice) has both spiritual and socio-economic functions, and its social value depends on orderly delivery to intended recipients. Community-based qurban programs in Indonesia continue to expand and diversify, increasing the need for transparent recording, entitlement determination, and distribution control [1], [2]. Operational studies have reported that manual qurban management can produce inaccurate recipient records, duplicate coupons, unequal distribution, and limited financial transparency [3]. Packaging and collection processes must also manage queue efficiency and hygiene, which become more difficult when volunteer committees verify claims under time pressure [4]. These risks underscore the need for a system that links recipient records, entitlements, coupon status, and transaction logs.

A similar situation occurs at Surau Kumango Pasa Gadang, located in Pasa Gadang Sub-district, South Padang District, Padang City, West Sumatra, which serves as the center of qurban implementation for the surrounding community every year. Table 1 summarizes the field data collected from the 2025 qurban implementation at this site.

As shown in Table 1, the 2025 qurban implementation involved eight participant groups, 56 participants, eight sacrificial animals, 448 small coupons, and 20 committee members. Processing 448 coupons within a concentrated distribution workflow created a substantial manual verification burden and opportunities for recording error, although this study did not quantify workload or error rates. Recipients were also classified into two entitlement categories: Category 1 for participants who were also recipients and Category 2 for recipients only. The paper process could not apply these distinctions automatically, so committee members had to determine and verify entitlements manually, particularly when a single person held multiple roles.

Paper coupons are susceptible to water damage, tearing, loss, illegibility, and forgery [5]. Under queue pressure, a committee may also be unable to consistently verify each coupon, leading to invalid or repeated claims [6]. At the study site, the volume of 448 coupons increased exposure to these failure modes. The same control problem is recognized in electronic-coupon systems: a centrally issued voucher can be redeemed repeatedly unless its state is checked and irreversibly changed immediately after a valid transaction [7].

Several studies have proposed digital alternatives to paper coupons. Laksono [8] designed a web-based digital qurban coupon verification system that applies AES encryption as an additional security layer to prevent forgery and misuse. In a related direction, the Ministry of Administrative and Bureaucratic Reform of the Republic of Indonesia, together with the government of the Republic of Korea, developed Verifiable Credentials, a digital identity standard that allows a person to be verified instantly through a QR code on a smartphone without disclosing their full personal data [9]; this privacy-preserving verification principle is relevant to the design of a qurban distribution system that must protect recipients’ personal information. Beyond documenting ownership, digital distribution systems also depend on a reliable mechanism to generate unique identifiers for every recipient; the Linear Congruential Generator (LCG) is a lightweight pseudo-random number generator that has been widely used in various computing applications for this purpose [10].

Real-world implementations further confirm the benefit of digitalization. Takyudin [11] reported that digitalizing qurban management at Masjid Al-Jauhar accelerated administrative processes by up to 60%, increased transparency through digital reporting, and raised congregational participation by 21.43%. This pattern is consistent with a broader trend across Islamic philanthropic institutions in the region, where fintech-enabled collection and distribution platforms are reported to improve the efficiency, accountability, and transparency of managing charitable funds such as zakat [12]. Erwansyah et al. [13] implemented a barcode-based coupon system at Musala An-Nur, North Sumatra, during Eid al-Adha 1446 H/2025, in which scanning a coupon automatically moved a recipient’s status from “not yet collected” to “collected,” enabling the committee to identify unclaimed shares in real time. Likewise, Lewenusa [6] applied a barcode-based queue and anti-duplication system at Musala Nurul Iman, South Jakarta, in which a coupon scanned more than once triggered a warning that the recipient had already collected their share.

A specific design gap nevertheless remained. The barcode systems reported by Lewenusa [6] and Erwansyah et al. [13] retained printed paper as the physical carrier, so damage or loss remained possible even though verification was digital. Five other qurban information-system studies addressed online coupons, stock reduction, recipient records, administration, or end-to-end animal management [14], [15], [16], [17], [18]. Among these five studies, none reported the combined use of deterministic identifier generation, database uniqueness validation, a keyed token digest, one-time-use state transitions, real-time duplicate-claim rejection, and category-based entitlement within one platform.

This study addressed the identified gap by designing SiKurban for Surau Kumango Pasa Gadang. Its contribution comprised five integrated controls: (1) an LCG to allocate deterministic initial identifiers, with each output checked against the database before issuance; (2) a QR code whose status could transition from available to used only once; (3) real-time rejection and logging of repeated redemption attempts; (4) automatic application of recipient-category entitlements; and (5) integration of data collection, token generation, QR-code issuance, scanning, distribution recording, and reporting. The LCG was not treated as a cryptographic random-number generator; uniqueness, integrity, and redemption control were implemented as separate safeguards.

The objectives of this study were to design and build a web-based qurban information system that replaces the conventional paper-coupon system using LCG-generated one-time-use QR codes; to implement real-time anti-duplication verification that automatically prevents duplicate meat collection; to design a recipient-classification feature so that entitlement corresponds to each recipient’s status and role; and to evaluate the functional correctness of the developed system using black-box testing. Accordingly, this study was guided by four research questions: (RQ1) How can a digital qurban information system be designed to replace the conventional paper-coupon system using an LCG-based unique-code-generation algorithm? (RQ2) How can a one-time-use QR-code mechanism with real-time anti-duplication verification be implemented so that every code can be used only once? (RQ3) How can a recipient-classification feature be designed so that meat entitlement corresponds to each recipient’s category? (RQ4) What are the functional testing results of the developed system, as measured by black-box testing?

2. Methods

2.1. Research Design

This study used an applied research and development (R&D) design to build a web-based information system, following the Waterfall software development model [19], as illustrated in Figure 1. The Waterfall model was selected because it suits a project whose specifications were clear and well-defined from the outset, following a linear sequence in which each stage is completed before the next begins [19]. The five stages were: Requirements, in which system needs were identified through consultation with the users, i.e., the management and committee of Surau Kumango Pasa Gadang; Design, in which the requirements were translated into a software and database architecture; Implementation, in which the design was converted into a running web application; Verification, in which the integrated system was tested to ensure it functioned as required; and Maintenance, in which the system was monitored and refined after being put into use.

2.2. Study Site and Stakeholders

The 2025 qurban event at Surau Kumango Pasa Gadang, Pasa Gadang Sub-district, South Padang District, Padang City, West Sumatra, Indonesia, supplied the manual-process baseline and the counts reported in Table 1. The same anonymized 2025 records were reused during the 2026 prototype-development and functional-testing cycle; these labels refer to one baseline event followed by system development, not two separate qurban events with identical counts. Field observation and informal interviews were conducted with the surau management and qurban committee to obtain a first-hand account of the manual distribution process, which involved six categories of actors under the existing manual system: the surau management, the head of the qurban committee, the data-collection committee, the distribution committee, qurban participants, and meat recipients. Based on the analysis of this existing process, the proposed system redefined the actors into five system roles with role-based access control: Admin, Data-Collection Committee, Distribution Committee, Surau Management, and Meat Recipient.

2.3. Development Instruments

SiKurban was developed as a server-rendered web application. The back end used the Laravel PHP framework with a Model-View-Controller (MVC) architecture, chosen for its mature ecosystem, broad community support, and built-in facilities for authentication, session management, data validation, and database migration [20], [21], which were managed through the Composer dependency manager [22]. The front end combined HTML5, CSS3, JavaScript, and the Bootstrap 5 framework to produce a responsive interface usable on both laptop and smartphone screens, complemented by the Chart.js library for interactive dashboards. MySQL served as the relational database management system. QR-code images were generated with the SimpleSoftwareIO/simple-qrcode library, camera-based scanning on the distribution-committee side used the jsQR library, and printable reports were produced with the Barryvdh/Laravel-DomPDF package. XAMPP and Visual Studio Code were used as the local development environment.

2.4. System Development Procedure

2.4.1. Requirements Analysis

Based on the field observation and interviews, 28 functional requirements and 13 non-functional requirements were identified. The functional requirements covered role-based login, user- and period-management, participant/group/animal data management, recipient-category management, LCG-based unique-code generation, QR-code creation and printing/downloading, QR-code scanning, real-time verification, one-time-use enforcement, hand-over confirmation, scan logging, monitoring dashboards, distribution reporting, National Identity Number (NIK)-based login for recipients, blank/emergency coupon issuance, a meat-portion calculator, bulk account generation, and an offline-ready scanning mode. The non-functional requirements addressed usability, performance, reliability, security, data integrity, anti-duplication control, browser compatibility, availability, backup and recovery, maintainability, auditability, privacy, and scalability. The 13 non-functional requirements were design targets only; the present evaluation did not operationalize or test them as acceptance criteria.

2.4.2. System Design

The system architecture was modeled using the Unified Modeling Language (UML), a widely used approach for visually representing a system’s actors, workflows, and class structure [23]. The model consisted of a use-case diagram involving five actors: Admin, Data Collection Committee, Distribution Committee, Surau Manager, and Recipient (Figure 2). It also included seven activity diagrams representing the Login, Manage Recipient Data, Manage Recipient Groups, Generate QR Code, Real-Time Verification through QR Code Scanning, Monitoring Dashboard, and Print Report or View Distribution Report workflows. In addition, a class diagram was developed comprising 14 interconnected classes.

The database was subsequently designed as an entity-relationship model containing 14 entities: Role, User, Qurban Period, Sacrifice Group, Qurban Participant, Sacrificial Animal, Recipient Group, Recipient, LCG Config, QR Code, Distribution, Log Scan, Report, and Coupon Bank (Figure 3). This approach is commonly used to identify an organization’s data requirements before physical implementation [24]. The model was implemented as 14 relational tables in MySQL: roles, users, periode_kurbans, kelompok_kurbans, peserta_kurbans, hewan_kurbans, golongan_penerimas, penerimas, lcg_configs, qr_codes, distribusi, log_scans, laporans, and kupon_blankos. These tables were connected through one-to-many and one-to-zero-or-one relationships, ensuring that each QR code, distribution record, and scan attempt could be traced to the corresponding recipient, generating user, and qurban period.

The design emphasized modularity, traceability, and role-based control. Each actor was assigned access only to functions relevant to their responsibilities, thereby reducing the risk of unauthorized data modification and minimizing overlap between data collection, verification, distribution, and reporting activities. Recipient and distribution data were linked through unique identifiers, while QR code generation and scan logs provided a verifiable record of each transaction. This structure allowed the system to distinguish between valid, previously used, expired, and unregistered QR codes during real-time verification.

The separation of recipient data, QR code records, distribution transactions, and scan logs also supported auditability. Every verification attempt could be recorded with its time, status, related recipient, and responsible user. Consequently, administrators and committee members could review distribution progress, identify duplicate or failed scans, verify the remaining allocation, and generate reports without manually reconciling paper coupons. The design therefore provided a consistent data flow from recipient registration and QR code generation to verification, distribution, monitoring, and reporting

2.4.3. Unique Token Generation Using a Linear Congruential Generator

The core novelty of SiKurban is the generation of a controlled, non-sequential initial code for every QR token using a Linear Congruential Generator, implemented in an LcgService class. The LCG recursive formula used is shown in Equation (1).

$$\text{Xn+1 = (a . Xn + c) mod m}$$(1)

where $\mathrm{Xn}$ is the current seed value, $a$ is the multiplier, $c$ is the increment, and $m$ is the modulus. Table 2 lists the parameter values used in SiKurban. The multiplier and increment in Table 2 are the Numerical Recipes constants. For a mixed LCG with modulus 2³², the Hull–Dobell full-period conditions require an odd increment and a multiplier for which (a − 1) is divisible by 4 [10].

Parameter	Symbol	Value
Multiplier	a	1,664,525
Increment	c	1,013,904,223
Modulus	m	2³² = 4,294,967,296
Initial seed (example)	X0	Stored per qurban period in lcg_configs

With state preserved between calls, the sequence therefore traverses 2³² states before repeating. Full period does not imply cryptographic unpredictability, so SiKurban used the LCG only to allocate identifiers and applied database and keyed-digest controls separately. Starting from X₀ = 3,975,605,359, the first iteration was X₁ = (1,664,525 × 3,975,605,359 + 1,013,904,223) mod 4,294,967,296 = 3,187,945,218. Its base-36 representation (1GQ0Q9U) produced the token QR-2025-1GQ0Q9U. Table 3 reports the ten sequential iterations recalculated from the stated seed and parameters. For a continuously persisted sequence within a period, the full-period configuration structurally prevents a repeated state before 2³² iterations. This within-period guarantee does not exclude overlapping numeric suffixes after a seed reset or across independently seeded periods; the period prefix and global database uniqueness check therefore remain necessary.

n	Xn (decimal)	Base-36 code	QR token
1	3,187,945,218	1GQ0Q9U	QR-2025-1GQ0Q9U
2	613,556,857	A5ANI1	QR-2025-A5ANI1
3	2,942,822,788	1CO2WLG	QR-2025-1CO2WLG
4	1,503,946,515	OVESK3	QR-2025-OVESK3
5	1,538,572,630	PG0Y8M	QR-2025-PG0Y8M
6	3,406,497,981	1KC52NX	QR-2025-1KC52NX
7	3,421,418,232	1KL0V7C	QR-2025-1KL0V7C
8	756,341,239	CIB0MV	QR-2025-CIB0MV
9	511,012,586	8G8RU2	QR-2025-8G8RU2
10	1,735,446,849	SP8NCX	QR-2025-SP8NCX

The values form a deterministic sequence generated from the stated seed; they are not cryptographic random values. Each token was also checked against the database and assigned an HMAC-SHA256 digest before issuance (Sections 2.4.3–2.4.4). For this revision, rows 1–10 were recomputed sequentially from X₀ using both Python integer arithmetic and JavaScript BigInt, and the decimal and base-36 outputs agreed. Table 3 is a formula-derived verification table, not a dump of production qr_codes records.

The LCG was retained in this prototype to provide a deterministic, reproducible identifier sequence with explicit state tracking, not because it offers stronger security or simpler collision handling than a cryptographically secure pseudorandom number generator (CSPRNG). Laravel/PHP can instead use CSPRNG-backed values, such as random_bytes()-derived identifiers or UUIDs, without maintaining deterministic LCG state. Such alternatives should be evaluated for production deployment when unpredictability is the primary requirement; this study does not claim that the LCG is superior to them.

Every generated value was validated against all existing tokens in the qr_codes table before being accepted; if a collision occurred, the generator iterated again with the updated seed, up to a maximum of 1,000 attempts, inside a database transaction protected by row-level locking (lockForUpdate()) to prevent two concurrent generation requests on the same period from producing a duplicate token.

2.4.4. Token Security

For token integrity checking, the application generated an HMAC-SHA256 digest of the token, qurban period identifier, and coupon type, using the Laravel application key (APP_KEY) as the secret [25]. The digest was stored with the token and recomputed during scanning; hash_equals() provided a constant-time comparison. This mechanism did not make the LCG sequence unpredictable and was evaluated only through the functional scenarios reported in this study, not through adversarial penetration testing.

2.4.5. One-Time-Use Verification Flow

When a distribution-committee member scanned a QR code, the system read the token and queried its status in the database in real time. Four conditions were distinguished: (i) a registered token with an active validity period and status “not yet used,” for which the system displayed the recipient’s data and offered hand-over confirmation; (ii) a registered token already marked “used,” for which the system rejected the scan, displayed the time and committee member of the earlier valid transaction, and logged the attempt as a duplication; (iii) a registered but expired token, for which the scan was rejected and the committee was directed to request a re-generated code; and (iv) an unregistered token, for which the scan was rejected and logged as an anomaly. Upon a valid hand-over confirmation, the status changed to “used,” the creation of the distribution record, and the scan-log entry were executed together in a single atomic database transaction protected by row-level locking, so that the QR-code status and the distribution record could never become inconsistent, even under near-simultaneous scans from two devices.

2.5. Testing and Data Analysis Technique

System verification used developer-executed black-box testing, in which the running application received specified inputs and its outputs were compared with expected results without using internal code structure as the test oracle [26]. Scenarios were derived from the 28 functional requirements and covered all five roles, as well as negative or edge conditions central to one-time-use verification, including repeated and unregistered tokens. A scenario passed when the observed output matched the predefined expected output; failed scenarios were corrected and retested. The 33 scenarios were executed on 1 July 2026. This procedure assessed functional conformance only; it did not measure usability, throughput, security resistance, user acceptance, or live-field effectiveness. All scenarios were designed and executed by the developer; no committee member or independent tester reran them. Accordingly, the 100% result is reported as developer-verified functional conformance, not user-acceptance testing or field validation.

3. Results

3.1. System Implementation Overview

Following the design in Section 2.4.2, the Laravel migration created all 14 database tables, and the system was implemented with five role-based interfaces: Admin, Data-Collection Committee, Distribution Committee, Surau Management, and a QR-code portal for Meat Recipients accessed through a National Identity Number (NIK) login rather than a conventional account, since most recipients do not have an institutional email address. The public landing page and login page used an emerald-green, dark-mode visual theme intended to evoke an Islamic identity. They displayed four live statistics — the number of qurban groups, participants, generated QR tokens, and registered recipients — retrieved directly from the database. Figure 4 shows the Distribution-Committee dashboard used on the day of distribution, which summarized overall progress (total, collected, and not-yet-collected recipients) together with QR-code integrity indicators (valid, used, and invalid/duplicate scan attempts) to support real-time field decision-making.

In the current prototype, the recipient’s NIK also served as the default credential. Because an NIK may be known to relatives or local officials or exposed through data leakage, NIK-only authentication is a current security limitation. Production deployment should require a forced credential change at first login or a separate one-time-password factor and should minimize the personal status information displayed before stronger authentication is completed.

3.2. LCG-Based Unique Token Generation

The LcgService class implemented generate(), which performed Equation (1); generateUniqueToken(), which generated and checked identifiers inside a locked database transaction; and generateSignature(), which produced the HMAC-SHA256 digest described in Section 2.4.4 (Figure 5). Recalculating the first 10 outputs from the documented seed reproduced the corrected values in Table 3. The developer reported no duplicate in the 448-token prototype generation run; no independent export of qr_codes rows or generation logs was available for audit. Within a continuously persisted period sequence, the full-period configuration structurally prevents a repeated state before 2³² iterations; this is not a probabilistic ‘negligible collision’ claim. Across seed resets or independently seeded periods, suffix overlap is not excluded, so the period prefix and global database check guard against resets, imported records, and concurrent requests.

3.3. One-Time-Use QR Verification Outcomes

Token condition	System response	Outcome
Registered, active, “not yet used”	Display recipient data; allow hand-over confirmation	Accepted
Registered, status “used”	Reject the scan; show the time and the committee member from the earlier transaction; log as a duplication.	Rejected
Registered, expired	Reject the scan; direct the committee to request a regenerated code	Rejected
Unregistered token	Reject the scan; log as an anomaly	Rejected

3.4. Recipient-Category Entitlement Outcomes

The implemented classification rule assigned Category 1 when a person was registered both as a qurban participant and a meat recipient, and Category 2 when the person was registered only as a recipient. In the tested workflow, the selected category was stored with the recipient record, carried into QR-token issuance, and used to display the corresponding entitlement before hand-over confirmation. Thus, a participant-recipient record followed the Category 1 rule, whereas a recipient-only record followed the Category 2 rule. The nine Data-Collection Committee scenarios summarized in Table 5 included recipient, category, and QR-generation functions and matched the developer-defined expected outputs. These observations demonstrate implemented rule execution only; allocation accuracy, fairness, and committee usability were not independently evaluated.

3.5. Developer-Executed Functional Testing Results

Black-box testing covered 33 scenarios across the five user roles: 28 positive scenarios for specified functions and five negative or edge scenarios for invalid login, duplicate QR issuance, reuse of a consumed token, an unregistered token, and deletion of recipient data with an existing distribution history. The developer recorded that all 33 scenarios produced the predefined expected outputs. This 100% scenario-pass rate denotes developer-verified functional conformance rather than independent validation or user-acceptance testing. Table 5 reports the module-level results.

Module	Scenarios	Passed	Failed	Success rate
Authentication (login/logout, all roles)	4	4	0	100%
Admin module (accounts, periods)	4	4	0	100%
Data-Collection Committee module (participants, groups, animals, recipients, categories, QR generation)	9	9	0	100%
Distribution Committee module (scanning, verification, hand-over confirmation)	6	6	0	100%
Surau Management module (monitoring, reporting)	4	4	0	100%
Meat Recipient portal	1	1	0	100%
Negative / edge-case scenarios (anti-duplication, invalid input)	5	5	0	100%
Total	33	33	0	100%

4. Discussion

All 33 black-box scenarios produced their predefined outputs, including rejection of reused and unregistered tokens. This result supports functional correctness for the specified cases in the development test environment; it does not demonstrate defect-free operation, scalability, usability, or field effectiveness. The result is consistent with barcode-based qurban studies in which a database-checked status helped identify completed and repeated collections [6], [13]. SiKurban extended that design by allowing smartphone access to the QR portal (Figure 6) while retaining a printable fallback. Consequently, dependence on paper was reduced but not eliminated. Printed codes also remain susceptible to copying or substitution, which has motivated tamper-resistant QR-code research beyond the qurban domain [27].

Compared with the five related qurban systems reviewed in the Introduction [14], [15], [16], [17], [18], SiKurban integrated identifier allocation, database collision handling, a keyed digest, one-time-use status control, and category-based entitlement. Prior applications of LCGs have emphasized their computational simplicity in examination randomization, order-code generation, quiz applications, and hybrid pseudo-random generators [28], [29], [30], [31]. The present study used that simplicity for identifier allocation rather than claiming cryptographic randomness. Table 6 consolidates this comparison and distinguishes features not reported in the cited publications from features demonstrated by SiKurban.

The technical role of the LCG also requires careful interpretation. Full-period conditions describe cycle length [32], whereas the statistical and lattice properties of congruential generators require separate evaluation [33], [34]. Accordingly, SiKurban did not rely on the LCG for secrecy. HMAC supplied a keyed integrity mechanism [35], while the database transaction and row lock were intended to serialize competing redemption updates; transaction-isolation research shows why these concurrency assumptions must be made explicit and tested [36].

QR-code security also extends beyond duplicate status. QR codes are untrusted input carriers, and cryptographic protection can introduce a security–usability trade-off by requiring denser payloads and more scanning constraints [37]. SiKurban’s functional tests did not evaluate malicious payloads, copied valid code, key compromise, replay across periods, or signature-handling errors. These cases should be included in a future threat model and independent security assessment. Recipient authentication introduces an additional present risk because the prototype uses NIK as the default credential. NIK-only access should not be treated as adequate production authentication; a forced first-login credential change or OTP-based second factor should be implemented and verified before live deployment.

The evaluation boundary is equally important. Information-system success includes system quality, information quality, use, user satisfaction, and net benefits, not only functional output [38]. Intended users conduct user acceptance testing in a realistic setting to determine whether software meets operational needs [39]. Thus, the present 100% test result should be read as a scenario-pass rate, and the next evaluation should compare SiKurban with the paper process using completion time, duplicate or invalid-claim handling, correction frequency, queue duration, and user-reported usability.

Finally, smartphone access does not by itself ensure equitable use. Digital-divide research distinguishes device or Internet access from differences in skills, use, and beneficial outcomes [40]. Retaining printable or assisted-verification options is therefore an inclusion safeguard, not merely a temporary implementation detail.

Operationally, a browser-based scanner can be deployed on ordinary smartphones without dedicated scanning hardware. Its reliance on real-time database checks, however, makes connectivity a material operating condition. The offline-ready requirement should therefore be validated through interruption, synchronization, and conflict-recovery tests before live multi-device deployment.

This study had eight principal limitations. First, it concerned one site and one qurban period, so transferability to larger or multi-location distributions is unknown. Second, testing was executed by the developer rather than independent testers or committee users. Third, throughput, concurrent multi-device scans, and unstable-network recovery were not stress-tested. Fourth, the study did not conduct penetration testing, a key management review, or adversarial analysis of token guessing and QR-code substitution. Fifth, it did not measure task time, error reduction, usability, satisfaction, adoption, distribution outcomes, or cost relative to the paper process. Sixth, the 13 non-functional requirements remained untested design targets. Seventh, NIK-only recipient authentication is a present vulnerability and is not suitable for production deployment without stronger credentials. Eighth, the zero-duplicate generation result relied on developer-observed application output; the underlying database rows and generation logs were not independently archived or audited.

Future work should prioritize independent user-acceptance testing with committee members during a live or high-fidelity distribution exercise, followed by load, concurrency, offline synchronization, and security testing. Before any live deployment, NIK-only recipient authentication should be replaced by a forced first-login credential change or an OTP factor, and administrative accounts should use two-factor authentication. Subsequent product extensions may include consent-based WhatsApp or SMS delivery, multi-location coordination, and cross-period analytics. Any digital-only workflow should retain an accessible fallback for recipients who lack compatible devices, connectivity, or digital skills.

5. Conclusion

This study designed and functionally evaluated SiKurban, a Laravel–MySQL web application for qurban meat distribution at Surau Kumango Pasa Gadang. The system combined deterministic LCG-based identifier allocation, database uniqueness checks, an HMAC-SHA256 digest, atomic one-time-use status transitions, and category-based entitlement. Recalculation corrected the documented ten-value LCG sequence, while all 33 developer-executed black-box scenarios produced their predefined outputs, including rejection of reused and unregistered tokens. These results establish developer-verified functional conformance under the specified conditions, not independent validation, user acceptance, non-functional quality, security resistance, or effectiveness in live distribution. SiKurban should therefore be regarded as a promising single-site prototype rather than a demonstrated field-effective alternative. Broader deployment requires independent user acceptance, comparative field and cost evidence, non-functional evaluation, scalability, offline recovery, and security testing before broader deployment.

Declarations

Author Contributions

Farras Fathin Naufal: Conceptualization, Methodology, Software, Investigation, Data Curation, Visualization, Writing – Original Draft. Dedy Irfan: Conceptualization, Supervision, Validation, Writing – Review & Editing. Delvi Asmara: Validation, Writing – Review & Editing. All authors have read and approved the final version of the manuscript.

Acknowledgments

The authors would like to thank the management and qurban committee of Surau Kumango Pasa Gadang, Padang, West Sumatra, for their cooperation during the requirements analysis and provision of operational context, and the Department of Informatics Engineering Education, Universitas Negeri Padang, for their academic support.

Ethical Approval

No clinical trials or experimental interventions on human or animal subjects were conducted in this study. The research relied solely on field observations, informal interviews with qurban committee members for requirements gathering, and anonymized operational data from system testing. Consequently, formal ethical clearance was deemed unnecessary.

Informed Consent

Verbal informed consent was obtained from all qurban committee members who participated in the requirements-analysis interviews and system demonstrations. Personal data of qurban meat recipients (e.g., name and National Identity Number/NIK) used to demonstrate the system were either anonymized or used with the consent of the individuals concerned, and are not disclosed in this manuscript beyond illustrative first names already shown in the source thesis.

Funding

This research received no specific grant from any funding agency in the public, commercial, or not-for-profit sectors. It was conducted as part of the first author’s undergraduate thesis at Universitas Negeri Padang.

Data Availability Statement

The data supporting this study’s findings are not publicly available. Summary data are included in the manuscript, and more detailed information can be requested from the corresponding author under strict confidentiality agreements.

Competing Interests

The authors declare that they have no competing interests related to the content of this article.

Generative AI and AI-Assisted Technologies Statement

During the preparation of this manuscript, the authors used AI (Claude) to assist with summarizing data, as explained in the manuscript. The authors reviewed, verified, and edited all AI-assisted content, including all citations and numerical values against the original thesis, and take full responsibility for the accuracy and integrity of the published work.