Testing a crypto payment integration means proving that the right order is fulfilled once, only after verified payment—not merely that a payment page opens. Separate message-delivery tests, your application's order-state tests and any authorized real-funds acceptance check. Each answers a different question.
This checklist is for developers and merchants preparing a payment flow for launch, including USDC or USDT payments where the selected asset and network are actually available. It is a recommended testing procedure, not a report that Yolfi has passed these tests for your application or provides a full testnet checkout.
Know which kind of test you are running
A simulated payment notification is not a blockchain transfer. A testnet transfer is not a payment on the production network. A successful browser redirect is neither.
| Test layer | What it can establish | What it does not establish |
|---|---|---|
| Application tests with controlled fixtures | Order transitions, rejection rules and duplicate handling | That the provider can reach your deployed receiver |
| Provider test webhook | Endpoint reachability and handling of the provider's test payload | That money moved or a real invoice was paid |
| Testnet transfer, where explicitly supported | Behavior on that particular test network | Production asset availability or mainnet settlement |
| Authorized live acceptance check | The observed result for one actual production payment | That every network, token and failure case works |
Ethereum's network guide explains that account balances and transaction history do not carry across independent networks. The same-looking address does not make testnet funds spendable on mainnet. Check the provider's current documentation rather than assuming that a generic wallet test applies to its payment service.
Start with a written test boundary
Record the application environment, provider account, receiver URL, signing-secret location, order IDs and intended side effects before sending anything. Use disposable customer records and disable real delivery, paid access and customer emails for simulated scenarios.
Keep test and production configuration separate. Never copy a signing secret into an article, screenshot, issue or chat transcript. Your test evidence should identify the secret version used, not expose its value. Do not request wallet recovery phrases or private keys from a buyer to investigate a failed test.
For a real-funds check, get explicit internal authorization for the amount, fees, destination and person responsible. Use a business-controlled wallet and an amount you can afford to lose. Do not send money to an address or network just because it appeared in an old screenshot, generated coin page or unofficial test instruction.
Prove that the server controls the order amount
In Yolfi API Checkout, the merchant server creates a Checkout Session with the final amount and currency. The buyer then selects a supported network and token, creating an Invoice from that session. A reusable Paylink serves a different purpose from a server-priced dynamic order.
For a dynamic cart, test your own server's price calculation and session association before testing money movement:
- Change a browser-supplied total and confirm it cannot override the authoritative order price.
- Try using another customer's order reference and confirm the application refuses unauthorized access.
- Refresh or reopen the payment flow and check that repeated attempts remain associated with the intended order.
- Change the cart after session creation and confirm the application has an explicit rule for replacing or rejecting the old payment attempt.
These are application acceptance criteria, not claims about a provider endpoint rejecting every possible request. Retain the server's order reference and the returned session reference together. Do not invent an API field or assume that a browser-controlled identifier proves ownership.
Send a test webhook without creating a real sale
The current Yolfi webhook documentation describes a dashboard test event sent through the same delivery path, adapter and signature header as live events. Its payload contains livemode: false and an evt_test_ event ID. The test does not create invoices, payment events, subscriptions or customer records.
Use that event to check delivery and payload handling—not settlement. A receiver returning 200 OK can still be incorrectly granting access or silently dropping the message. Inspect the resulting application state as well as the delivery result.
Verify signatures using the documented procedure and the endpoint-specific signing secret, not the organization API key. Confirm that your live fulfillment path cannot treat a test event as a paid order. If you exercise fulfillment with fixtures in an isolated test environment, use disposable records and inspect those records separately from production.
Yolfi requires a public HTTP or HTTPS destination and does not follow redirects. For local development, its documentation recommends a public HTTPS tunnel. Check the exact final receiver URL; a successful request to a different path or a local-only address does not prove provider delivery.
Use a failure matrix, not just a happy-path screenshot
Run controlled fixtures against your own isolated test environment for cases the provider's test sender does not expose. Clearly label these as application tests; do not present fabricated provider events as real payment evidence.
| Scenario | Required observation in your application |
|---|---|
| Valid test event | Recorded as a test; no live delivery or paid receipt |
| Missing or invalid signature | Rejected before changing an order |
| Payment initiated but not confirmed | Order remains unpaid |
| Confirmed payment for an unknown order | Held for investigation; no guessed customer match |
| Same signed event delivered twice | One durable business result, no duplicate delivery |
| Two workers process the same event | One fulfillment decision despite concurrent handling |
| Receiver unavailable, then restored | Recovery observed without double fulfillment |
| Browser closes before returning | Payment processing does not depend on the return page |
For Yolfi, invoice.created signals initiation; payment.confirmed is the documented fulfillment trigger. Do not promote an order to paid merely because the first message arrived. The idempotent webhook guide covers durable deduplication; this checklist focuses on collecting evidence that your implementation actually behaves that way.
Test recovery deliberately. A process that returns success before storing an event can lose work if it crashes. A process that delivers goods before recording completion can repeat delivery after a retry. Choose a durable processing design, then exercise interruption points rather than assuming a single successful request proves reliability.
Check the buyer's instructions and unresolved-payment path
Open the actual payment flow on a phone and desktop. Check that the displayed amount, selected asset, network, destination and expiry information are understandable before a transfer. Test copy controls and QR scanning without assuming that a QR code automatically configures every sending wallet correctly.
Do not send an unsupported token, deliberately use the wrong network or make an irreversible transfer solely to test an error message. Rehearse those support situations with controlled records instead. The wrong-network prevention guide explains the buyer-facing checks to include.
Rehearse an unpaid or expired order: the buyer should receive a clear status and a safe next step, not an unsupported promise of recovery. Use the expired-invoice procedure to decide what to investigate before asking for another payment. A second payment must not become the automatic answer to an unclear first attempt.
If authorized, document one live acceptance check
Only proceed after confirming that the chosen production asset and network are available in the actual flow. Account for any required network fees and keep the destination under business control. A provider test webhook does not justify sending live funds through an unverified route.
Record the order and payment references, actual asset and network, amount, observed confirmation, receiving-wallet evidence and resulting fulfillment state. Avoid promising a universal confirmation count or settlement time. Check the result you actually observed, not just a wallet screenshot.
Then reconcile that payment against the order and receipt records. The reconciliation checklist helps distinguish incoming funds from order allocations and fees. If you plan to refund the acceptance payment, authorize and verify the refund separately; do not assume it is an automatic reversal.
A passing check establishes one observed route at one point in time. Repeat relevant acceptance tests when payment logic, receiver deployment, secrets or supported routes change. Never generalize one USDC payment into proof that all USDT networks work.
Keep a release evidence record
Save a concise report with the tested application version, environment, scenarios, expected results, actual results and unresolved issues. Link to private logs and order records rather than publishing customer identifiers or full wallet histories.
Block launch if a test event can fulfill a live order, a duplicate can deliver twice, invalid signatures can change state or confirmed payments cannot be matched safely. Assign an owner to each unresolved item. A green delivery badge is not a substitute for these business outcomes.
Frequently asked questions
Does a Yolfi test webhook move crypto?
No. The documented test validates delivery and payload handling without creating invoices or payment records. It does not prove that a real blockchain payment succeeded.
Is a testnet payment the same as a payment-service sandbox?
No. A testnet is a separate blockchain network. A provider sandbox is a service-specific environment. Verify whether the provider supports the particular mode you need; this article does not establish a Yolfi testnet checkout.
Can I launch after the payment page redirects successfully?
Not on that evidence alone. Verify server-side payment handling, order matching, duplicate protection and failure recovery. The buyer may close the browser before any return page opens.
Must I test every failure by sending real money?
No. Use isolated application tests and documented provider simulations for failure handling. Any live acceptance check needs authorization and a verified supported route, not deliberate transfers to wrong networks.
Conclusion: test the business result before launch
Start with a clear boundary, prove server-side order handling and distinguish a simulated event from verified funds. Use Yolfi payment links for suitable fixed-price offers or the documented API flow for dynamic orders, then keep evidence that payment processing—not the browser redirect—controls fulfillment.
