Crypto Payment Integration:
A Credit-State
Evidence Sheet
Dmytro Nasyrov PhD
The credit-state evidence sheet
Field
Evidence to record
Asset and network
Specify the route, including the chosen connector.
Transaction reference
Identify the transfer within that route and its account mapping.
Confirmation-policy revision
Name the operator policy that governs eligibility for credit.
Credit state
State what the account system currently records.
Ledger evidence reference
Locate the corresponding account posting or unresolved record.
Review owner
Assign the policy and ledger evidence requests.
Fictional deposit D51
Assume a designated ETH route on Ethereum and a fictional transaction reference TX51. The connector sends notifications N51 and N52 for the same deposit D51.
The handover includes the two notification records. It omits the applicable confirmation-policy reference and a correlated account posting.
TX51 is a teaching label, not a usable transaction hash. No chain lookup, wallet access, transfer or account credit occurs in this example.
Completed sheet for D51
Field
Fictional entry
Asset and network
ETH / Ethereum / selected connector in the brief
Transaction reference
TX51, mapped to synthetic deposit D51
Confirmation-policy revision
Missing from the handover
Credit state
UNRESOLVED in this proposed review
Ledger evidence reference
Correlated account record requested, not supplied
Review owner
Operator payment-policy owner and ledger reviewer
Notification, chain record and account credit
Record
Question it can answer
N51 and N52
Which connector notices arrived for D51?
Transaction and receipt evidence
What does the selected network record for the transfer?
Confirmation-policy revision
Which conditions must the operator review before credit?
Account ledger record
Which posting, if any, corresponds to the approved deposit?
Keep the policy decision and account posting linked to the same deposit identity.
The repeated notification
In the declared D51 scenario, N52 reports the same transaction and account mapping as N51. Record both delivery attempts under the original deposit identity.
Request the account record before asserting that the duplicate notice caused another credit. If its asset, network or account mapping differs, open an identity exception.
The absence of a policy reference keeps the review unresolved. Repeating a notification cannot supply that missing policy.
Policy gaps and credit review
Evidence condition
Proposed next action
Policy revision missing
Ask the operator policy owner for the applicable revision.
Network evidence incomplete
Request the permitted transaction evidence for this route.
Ledger link missing
Assign the account reviewer to locate the deposit record.
All required evidence available
Review the agreed credit conditions and record the decision.
Any reversal or chain-change handling belongs in the approved payment contract.
Receipt data has a defined scope
Ethereum's JSON-RPC documentation describes transaction receipts with fields such as transaction hash, block hash and execution status.
Those network fields belong beside the operator's confirmation-policy revision and account evidence. The receipt format does not define the casino's crediting decision.
Crypto cashier integration scope
Gambit Stream offers crypto payment integration for an existing casino account system.
Its published scope includes deposit detection, confirmation policy, account crediting, withdrawal states and reconciliation. Use the D51 sheet to agree which records support a credit decision.
Specify each asset with its network and connector. Bring the existing account contract and identify who owns payment policy and ledger acceptance.
About the author
Written by Dmytro Nasyrov PhD, software architect with 24 years of production experience. Dmytro is the founder of Gambit Stream. He works on production software architecture for iGaming platforms and integrations.
Dmytro Nasyrov. Photo supplied by the author.