Why you should know this
“Confirmed” sounds finished. In crypto remittance, it may mean only that a blockchain recorded a transfer. A receiving provider might still need to detect it, check information, convert it to PHP and credit the recipient.
The reverse can also happen: an app may say “processing” while no network transaction has been broadcast. Searching a block explorer then produces nothing, because the transfer is still inside the provider’s system.
Understanding these layers prevents panic, duplicate sends and fake-support scams. It also builds a market-mastery habit: never treat one data point as proof of the entire process.
One remittance, several records
A compliant crypto-enabled route can create at least three records:
- Provider record: the sender’s order, identity review, conversion and withdrawal instruction.
- Network record: the virtual-asset transfer and confirmations on a blockchain.
- Receiving and PHP-delivery record: asset detection, compliance review, conversion and bank/e-wallet/cash delivery.
Some providers keep the crypto movement entirely inside their own or partner systems, so the customer may never receive a public transaction hash. Others show one. Neither design alone proves that a service is safer or faster.
Track each layer separately. Do not assume the same status word has the same definition across companies.
Common status words, translated
Created or initiated
The user entered an instruction, but the provider may not have accepted funds or begun processing. Check whether payment, identity information or confirmation is still required.
Pending payment or funding
The order is waiting for the sender’s money. Sending an incorrect amount, using a different payer name or missing a deadline can stop progress. Use only the official instructions tied to the order.
Under review or verification required
The provider may need identity, source-of-funds, beneficiary, sanctions or transaction information. This is not automatically an accusation. Regulated providers perform risk-based checks.
Respond only through verified channels. Never send an OTP, password or seed phrase. Ask what document is required, why, how it will be protected and the official upload method.
Approved or processing
The provider accepted the instruction and is preparing the next step. “Processing” does not establish that a network transfer exists. Look for a transaction hash only if the service says it will provide one.
Broadcast or submitted to network
The transaction was sent to a blockchain. A hash should normally identify it. Verify the asset, network, destination and amount—not just a green icon in an app.
Pending network confirmation
The blockchain has seen the transaction but has not reached the provider’s required confirmation threshold. Congestion, fees, chain design and risk policy affect timing.
Do not send again merely because confirmation is slow. A duplicate transaction may become a second valid transfer.
Confirmed or finalized on network
The network accepted the transaction to the relevant degree. This is an important milestone, not proof of final PHP delivery.
Different networks and providers use different ideas of finality and confirmation counts. The receiving provider may still be matching a memo or destination tag, applying controls or waiting for internal crediting.
Detected or received by provider
The receiving system recognized the incoming asset. It may not yet be available for conversion or withdrawal. Check whether the provider says the asset is credited, available or still on hold.
Credited
The balance appeared in the recipient’s account. Identify what was credited: crypto, PHP e-money or a bank deposit. These have different risks and next steps.
Conversion pending or converted
The provider is exchanging the asset for PHP, or has completed that step. Record the executed rate, fees and peso amount. A conversion estimate may differ from the final execution under disclosed terms.
PHP payout or Withdrawal pending
The peso instruction has been sent or queued for a bank, e-wallet, cash outlet or another delivery channel. The external rail may have its own cutoff, maintenance window, limit or exception.
Completed
Completed should mean the route reached its defined endpoint. Confirm the recipient’s actual credit independently. A screenshot from the sender is not the same as a bank or wallet balance checked by the recipient.
Rejected, failed, cancelled or expired
The transaction did not proceed under the provider’s rules. These terms are not interchangeable. Find out whether funds were ever collected, whether a blockchain transfer occurred, and whether a refund is due.
Returned or refunded
Value is being sent back or re-credited. The returned amount can differ because of non-refundable fees, FX movement or the return method, subject to applicable terms and law. Ask for the amount, destination, reason and estimated process—not a guarantee.
The two-ledger test
When a public network is involved, compare two facts:
- On-chain fact: What does the transaction hash show?
- Provider fact: What does the provider’s case or order record show?
Imagine the explorer says “confirmed,” while the app says “deposit not credited.” That narrows the issue to asset/network support, destination, memo/tag, provider detection or compliance—not network broadcast.
If the app says “processing” and there is no hash, the provider may not have broadcast anything yet. A blockchain explorer cannot solve an internal review.
What a transaction hash can and cannot prove
A hash can help show the sending and destination addresses, asset movement, network fee, block and confirmation status. It cannot by itself prove:
- the legal identity of either person;
- that the recipient controls the address;
- that required beneficiary information was complete;
- that a provider credited its customer;
- that crypto was converted to PHP;
- that a bank or wallet delivered the pesos;
- that a purchase or obligation was legitimate.
Public explorers may expose address activity. Share a hash only when necessary and consider privacy implications.
A safe evidence packet
For official support, prepare:
- provider order or case ID;
- date, time and timezone;
- asset, network and amount;
- transaction hash, if applicable;
- sender and recipient method with masked identifiers;
- current status and last change;
- error message copied accurately;
- screenshots with sensitive data removed;
- the outcome requested: trace, correction, refund or explanation.
Do not include a password, private key, seed phrase, OTP, unmasked ID or full payment-card information. Genuine support does not need control of your wallet to investigate a transfer.
Four fictional diagnoses
Case 1: “Processing,” no hash. Check the provider order for verification or funding requirements. Do not pay a stranger to “accelerate the blockchain.”
Case 2: Hash confirmed, provider not credited. Confirm asset, network, destination and memo/tag. Open a case with the receiving provider using the hash.
Case 3: Crypto credited, PHP absent. The issue is likely conversion or payout, not network confirmation. Check executed conversion and delivery status.
Case 4: Sender says complete, recipient sees nothing. The recipient checks the official bank/e-wallet account directly. Both parties compare the transaction ID and masked destination, then contact the responsible provider.
When to wait and when to escalate
Read the provider’s current stated processing window and maintenance notice first. Escalate when the window is exceeded, the status contradicts verified records, sensitive information is demanded, the destination appears wrong or an unauthorized transfer is suspected.
Contact the provider through its official channel and keep the case ID. For BSP-supervised institutions, the BSP Consumer Assistance Mechanism is generally a second-level route after first raising the matter with the provider, subject to its scope and current rules. Law-enforcement or fraud reporting may also be appropriate for suspected crime.
Philippine scenario
Liza sees “network confirmed” for a family transfer, but her bank has no PHP credit. Her brother nearly sends again. Instead, they check the hash, confirm the receiving address, and see that the provider status says “conversion review.” They open one official case and preserve the record.
Nothing in that process guarantees recovery or timing, but it avoids creating a duplicate transfer and gives support usable evidence.
How this connects to market mastery
Trading systems also have layered states: order submitted, accepted, partially filled, filled, settled and withdrawable. Confusing them produces operational risk.
By learning to distinguish network finality from provider settlement and fiat delivery, you practice the same careful state analysis used in professional operations.
Key takeaways and check
- One remittance may have provider, blockchain and PHP-delivery records.
- “Confirmed” may refer only to the network.
- A transaction hash proves limited technical facts, not the complete outcome.
- Diagnose the layer before acting, and never duplicate a send impulsively.
- Escalate with masked evidence through official channels.
Developing check: For four fictional transfers, name the current layer, missing evidence and safest next action.
*Cryptocurrency and virtual asset transactions are highly volatile and irreversible, may result in significant losses, and do not guarantee returns; customers should trade only after understanding the risks involved.
