CodeCanyon XRP Ledger Crypto Payments Support - WordPress Plugin

How to Configure CodeCanyon XRP Ledger Crypto Payments Support for WordPress Payments

CodeCanyon XRP Ledger Crypto Payments Support is not meant to work as a standalone checkout system. It adds XRP Ledger support to the CryptoPay ecosystem. In this guide, we'll walk through how to prepare your WordPress site, where to find the settings after installation, how to tie an XRP payment to an order, how to verify the result, and which signs indicate that a payment was not matched to the order correctly.

This article is intended for WooCommerce store owners, webmasters, and developers who already understand the basics of crypto payments but want to build a working setup without risky guesswork. We will not cover buying the product itself, entering purchase codes, or activation workarounds. The focus here is on using the plugin you already have, validating the settings, and troubleshooting safely.

One important caveat: the public CodeCanyon product page confirms the product name and its purpose as XRP Ledger support for CryptoPay, but detailed public documentation for this specific add-on is limited. Because of that, exact names of internal tabs and fields are described carefully in this article, and the practical steps rely on standard WordPress and WooCommerce behavior, CryptoPay-style payment extension logic, and official XRP Ledger documentation.

What the XRP Ledger Support Layer Actually Solves in CryptoPay

A typical WooCommerce payment plugin has to take the customer from cart to checkout, show clear payment instructions, receive confirmation from the payment system, and update the order status. For card payments, that work is handled by the processor. With crypto payments, part of that logic moves into the blockchain layer: the customer needs to see the address, amount, and sometimes a destination tag, then the system must wait for the transaction, verify it on the network, and connect it to a specific order.

With XRP Ledger, two things matter most: payment identification and verification of the final result in a validated ledger. XRP Ledger documentation explains that the destination tag helps external systems understand which customer, account, or order an incoming payment belongs to. It also makes clear that a preliminary server response should not be treated as the final transaction result. Your application should rely on the validated outcome.

That is why CodeCanyon XRP Ledger Crypto Payments Support should be viewed as a bridge between three layers:

• The WordPress admin area, where the plugin is enabled and CryptoPay settings are defined.
• The WooCommerce order, where the amount, status, payment method, and notes are stored.
• The XRP Ledger, where the customer sends XRP and where the incoming payment is verified.

This kind of product is useful when a store wants to accept XRP or test crypto payments without building a heavy custom integration from scratch. But it is not a universal replacement for every payment method. Crypto payments come with volatility, accounting considerations, the risk of user error during transfer, dependence on third-party APIs or nodes, and the need to explain clearly what the buyer is expected to do.

The main setup principle: first get a stable test payment and a clear "order - amount - address - tag - transaction" match, and only then expose the method to real customers.

Who This Payment Method Fits - and When Another Option Makes More Sense

This plugin makes sense for sites where buyers are genuinely willing to pay in XRP: digital products, subscriptions with manual review, niche services, international orders, or communities that are comfortable with cryptocurrency. If your audience is used to credit cards, fast local payment systems, and instant refunds, XRP is better offered as an additional option rather than the only way to pay.

Good-fit scenarios

This product works best in situations where the order can be processed after payment confirmation, not where every second is critical. For a digital product, that might mean granting access after payment. For a service, it could mean recording the request and then reviewing it manually. For a private membership or community, it may simply mean confirming the contribution. In all of these scenarios, the administrator can compare the order, amount, and transaction if the automatic match fails.

It also fits developers who already use CryptoPay as their main crypto payment layer and specifically want to add XRP Ledger instead of moving to a different aggregator. That distinction matters: this add-on supports one specific payment route inside an existing setup. It does not replace the whole store, and it does not solve tax, legal, or accounting requirements on its own.

When to pause and reconsider

If your store sells products that are fulfilled instantly and a misapplied payment creates financial risk, the setup must be handled very carefully. Do not enable automatic access delivery until you have tested how the plugin handles partial payments, incorrect amounts, duplicate payments, expired invoices, payments without a tag, and delayed verification. If your version of the product does not provide the controls you need for those cases, it is better to leave the order pending and review disputed incoming payments manually.

You should also avoid this payment method if you are not prepared to explain where the buyer should send XRP, what to do with the tag, how long confirmation may take, and where to contact support if something goes wrong. With crypto payments, the problem is often not the technology itself but an interface that is not clear enough. The customer sees an address, copies an amount, sends payment from a wallet, and waits. If the order page does not provide clear instructions, support volume goes up quickly.

What to Check Before Installing It on a Live Site

Before installation, it helps to split preparation into three areas: technical, payment-related, and operational. The technical side is about compatibility between WordPress, WooCommerce, CryptoPay, and your theme. The payment side covers the address, network, fees, matching logic, and verification. The operational side covers what the administrator should do if the customer sends the wrong amount or forgets to include the destination tag.

Technical compatibility

Start by confirming that the core payment flow works without the XRP add-on. WooCommerce should create orders correctly, display payment methods under WooCommerce > Settings > Payments, send emails, and save order notes. If the store already has checkout problems, adding a new crypto payment method will only make diagnosis harder.

Then confirm that CryptoPay is installed and configured at a basic level. Since this product is XRP Ledger support for CryptoPay, it normally should not be expected to work inside an otherwise empty WordPress site without the parent layer. If you do not see any new options after activation, first make sure the main CryptoPay plugin is active and that your version is compatible with the add-on.

Payment preparation

For XRP Ledger, prepare a working address, a test scenario, and clear matching rules in advance. If one address is used for many orders, be especially careful with the tag. Official XRP Ledger documentation explains that tags do not change ledger behavior by themselves, but they help an external system decide how to process incoming funds. For a store, that leads to one simple rule: if the tag is part of the order-matching logic, the customer should see it as clearly as the address and the amount.

Check whether your wallet or infrastructure can receive payments with a tag, how you will inspect transactions in an explorer, and where your order history is stored. For a live store, it is not enough to rely on an email from the customer saying "I already paid." You need a verifiable chain: order number, amount, address, tag, and transaction hash.

Operational rules

Before enabling the payment method for customers, agree internally on what to do in disputed cases. For example: a partial payment keeps the order pending, an overpayment is recorded in the note, a payment without a tag is reviewed manually, and a repeated transaction must not automatically trigger duplicate product delivery. It is best to write these rules into a separate support procedure, because disputed crypto payments usually require calm verification rather than quick edits in the admin panel.

Installation and First Validation in WordPress

Installation follows the normal pattern for a commercial WordPress plugin: upload the ZIP package, activate it, check dependencies, and open the settings. But payment add-ons have an important nuance: a successful activation does not mean the method is ready to receive money. You still need to confirm that the payment route appears in the right place, is available during checkout, and behaves correctly in a test purchase.

Basic action sequence

1. Open Plugins > Add New and upload the plugin ZIP file through Upload Plugin.
2. Activate the add-on and check whether there is any notice about a missing parent plugin.
3. Open the CryptoPay settings or the WooCommerce > Settings > Payments section if the integration appears as a WooCommerce payment method.
4. Find the option related to XRP Ledger and enable it only after checking the required fields.
5. Clear the checkout page cache if the store uses a caching plugin or optimizer.

If the method does not appear in the payment list, do not start by reinstalling the plugin. First check whether WooCommerce and CryptoPay are active, whether the method is being hidden by store currency, customer country, minimum amount, or test mode conditions, and whether any required parameters are still empty. Payment gateways often stay hidden at checkout until all mandatory settings are filled in.

Initial check after activation

Create a low-cost test product and go through checkout as a regular customer. The goal of this test is not to send a large payment, but to confirm that the customer path is clear: the payment method appears, instructions show up after selection, the amount is preserved, the order is created, and the expected status is visible in the admin area. In WooCommerce, orders and order statuses are the central control point, so the order itself should be your main place of verification, not just the wallet page.

If the customer lands on a blank page after selecting the method, sees the wrong amount, or does not receive payment instructions, do not move on to real payments. Fix the checkout flow before the first public launch.

Detailed Configuration After Installation

This section should answer one simple question: which parameters need to be checked so an XRP payment does not get stuck somewhere between the blockchain and the WooCommerce order. Public sources do not provide exact names for every field in the add-on, so the checklist below is a practical settings map that you should align with the interface in your version of CryptoPay and the XRP extension.

Address, network, and operating mode

The first settings group is usually tied to the recipient address, verification mode, and whether the method is active. Make sure the address entered is an XRP Ledger address, not an address from another network. If the interface offers a test mode or live mode, begin with a test scenario or the smallest real amount you can safely verify. Do not use an exchange address unless you fully understand the tag rules involved: exchanges often require a destination tag to credit funds, and your store must give the buyer an unambiguous instruction.

If the plugin lets you define the payment method label, use plain language. A good option is "Pay with XRP via XRP Ledger." A bad option is an unexplained technical abbreviation. The customer should understand that they need a wallet that supports XRP Ledger, not just any cryptocurrency and not a transfer on some other network.

Order-to-payment matching

The most important setting is how the plugin determines that a specific transaction belongs to a specific order. In XRP Ledger, that may involve the amount, address, destination tag, internal order ID, invoice expiration window, and transaction hash. Not all of these may be available in your version of the product, but the verification principle is the same: each order should leave a payment trail that is distinct enough to identify it reliably.

If the plugin uses a tag, check whether it is unique per order or per customer. If it relies only on the amount, evaluate the collision risk: two buyers can place orders for the same total. If a payment timeout is available, set it so the customer has enough time to send payment, but old invoices do not remain active for too long. For manual review, it is useful if the transaction hash is saved either in the order notes or in a separate CryptoPay log.

Order statuses

For WooCommerce, you need to decide which order status is applied at each stage. A common safe path looks like this: pending payment after checkout, processing or completed after a valid payment is detected, and pending manual review when something is wrong. Do not enable automatic access delivery until you have verified that the plugin can correctly distinguish a confirmed transaction from one that is unconfirmed, partial, or tagged incorrectly.

If the store sells digital goods, the status may immediately trigger file delivery or account access. In that case, test the full path on a dedicated product first. If you sell physical products, the processing status usually tells the team to begin fulfillment, but it does not automatically resolve returns, shipping, or accounting questions.

Customer payment instructions

The customer should see a short instruction that explains which network to use, where to send the XRP, how much to send, whether a tag is required, how long verification may take, and what to do if something goes wrong. Do not overload the page with blockchain theory, but make sure the critical elements appear together. If the tag sits on a separate line, visually separate it from the address and add a warning that it must not be skipped when required for the order.

After saving the settings, test the checkout page in a normal browser window, not just inside the admin area. Some themes, builders, and optimizers change the visibility of payment blocks. If the instruction appears in the admin area but the buyer cannot see it, the issue may be caused by the checkout template or page caching.

Configuring the Customer Payment Instructions

Crypto payments have a trait that is often underestimated: the user performs a critical part of the process outside your site. They open a wallet, copy the address, enter the amount, choose the network, add the tag, and confirm the transfer. The plugin can prepare the payment details, but it cannot correct every mistake inside a third-party wallet. That is why the payment instructions must not be decorative text. They are part of the order-processing logic.

A good instruction does not contain a long explanation of blockchain basics. It contains short, verifiable actions. The buyer should understand that they need XRP Ledger specifically, that the amount should not be rounded by guesswork, that the tag must not be skipped when shown, and that the order will update after verification. If your store serves Russian-speaking customers, do not leave technical phrases unexplained. For example, next to Destination Tag, you can write: "used to match the payment to your order."

Which elements should appear together

On the payment page, it helps to group the details into one block so the user does not have to jump between the address, amount, and notes. If the address is long, use line breaks and a copy button if your version of the product or theme provides one. If no copy button exists, do not add a homemade script without testing it on mobile devices: bad address copying is more dangerous than not having a polished button.

• The payment amount should be shown separately from the store-currency order total.
• The recipient address should be easy to read and should not be truncated by theme CSS.
• If a tag is used, it should be highlighted as a required field, not treated like a minor note.
• The payment window should explain when it makes sense to place a new order or contact support.
• Support contact details should appear near the instructions if manual review is actually available.

How to test the instructions without a real customer

Ask someone who did not configure the site to go through a test order and say out loud what they are about to send. If they ask which network to choose, where to paste the tag, or why the XRP amount differs from the product currency, the instructions are not clear enough. This kind of test quickly exposes issues the administrator may overlook simply because they already know the correct flow.

Check the mobile layout separately. Long addresses and technical strings often break the layout on phones first. If the payment block stretches the checkout page, overlaps a button, or hides the tag behind horizontal scrolling, the buyer may send the payment incorrectly. In that case, it is better to simplify the styling and make the block more vertical than to force everything into a single line.

Payment Matching, Expiration Windows, and Manual Review

For a store, the important thing is not simply that a transaction happened on XRP Ledger, but that the transaction is correctly tied to a specific order. In the ideal case, the plugin finds the incoming payment on its own, verifies the amount, tag, and finality, and then updates the order status. But the administrator still needs to know what to do when that ideal flow breaks down.

Why the amount alone is not enough

It may seem tempting to match payments using only the amount: an order for 25 XRP, an incoming payment for 25 XRP, so everything must line up. In practice, that is a weak criterion. Two buyers can place the same order, one can send the payment later, another can recreate the order, and the exchange rate can change between checkout and payment. That means the amount should be only one signal, not the sole proof.

A more reliable model uses several signals at once: address, amount, tag, time, invoice lifetime, and hash. If your version of the product exposes fewer data points, compensate with a manual review procedure. For example, do not change the order status if only the amount matches but the tag is missing and several similar orders were placed during the same period.

Payment expiration time

If the payment window is too short, it frustrates the buyer: they place the order, open the wallet, verify the address, and the invoice is already expired. If it is too long, a different risk appears: old invoices remain active while the exchange rate and order context may have changed. For digital products, a moderate payment window usually works well, as long as you clearly tell the buyer that once it expires, the order should be placed again.

If the settings do not include a dedicated expiration period for the XRP invoice, use an operational support rule instead: do not auto-credit old unpaid orders without verification. This matters even more if product prices change or the store uses discounts, coupons, or limited-time offers.

Manual review without chaos

Manual review should follow the same procedure for every team member. Open the order and check the amount, creation time, expected tag, customer comments, and transaction hash. Then open an XRP Ledger explorer or another reliable verification source and compare the details. If everything matches, you can update the status and leave a note describing which hash was checked, what amount was received, and who performed the review.

Do not delete disputed orders right away. It is better to keep them as a record of a payment attempt, especially if the customer contacts support later. Deleting the order removes context: what amount was shown, which tag was expected, which email the customer used, and when they placed the purchase.

Compatibility with the Theme, Checkout Blocks, and Optimization Plugins

A payment method can be configured correctly in the admin panel and still display incorrectly on the public side of the site. The reason is often not the XRP add-on itself but the surrounding environment: the theme overrides WooCommerce templates, a builder changes checkout behavior, an optimization plugin defers scripts, caching serves an outdated page fragment, or minification breaks the logic that handles payment method selection.

Classic checkout and block-based checkout

WooCommerce continues to develop block-based checkout experiences, but not every payment extension supports classic checkout and block checkout equally well. If the XRP method does not appear in the newer block-based checkout, test it in the classic shortcode-based checkout first. That is not a final answer, but it is a quick way to see where the issue sits: in the payment logic itself or in a specific checkout implementation.

If the store is already built around blocks and cannot switch back to classic checkout, review the CryptoPay and add-on documentation for compatibility details. Do not promise the payment method to customers until you know it works reliably in your exact checkout setup. For a commercial store, "visible in the admin panel" is not the same as "works during checkout."

Caching and script optimization

Cart, checkout, and payment pages must always receive fresh data. If a caching plugin stores HTML containing another customer's address, an outdated amount, or an expired tag, that is a critical issue. Exclude checkout, cart, thank-you pages, and account pages from static caching. Also review any JavaScript optimization settings: deferred loading can interfere with how the selected payment method updates on the page.

After changing cache settings, create a new order in a private browser window. Do not test only as an administrator: many optimizers avoid caching pages for logged-in users, so the admin sees fresh data while real customers may still get stale content.

Status, subscription, and membership plugins

If the store uses subscriptions, memberships, LMS access, or custom order statuses, check which event actually triggers access delivery. Some plugins wait for completed, others respond to processing, and others use their own hooks. The XRP add-on may confirm the payment correctly, but access will not be granted if another plugin is waiting for a different status.

For more complex sites, it helps to create a simple internal matrix: which product is being sold, which status should follow an XRP payment, which email is sent, which access is granted, and who receives an alert when something fails. That table does not belong in customer-facing content, but it is useful inside the team. It reduces the risk of a payment going through while the order gets stuck because two systems expect different rules.

How the "Order - XRP Payment - Confirmation" Chain Works

To avoid treating the plugin like a black box, it helps to understand the overall flow. The customer creates an order, selects the XRP payment method, receives payment details, and sends the transaction. The system then needs to detect the incoming payment, verify the amount and payment details, confirm that the result is final, and update the order status. If any of those steps fails, the order either gets stuck or requires manual review.

Why the destination tag matters so much

In XRP Ledger, one address can receive payments for many customers. The documentation explains that the destination tag helps external systems route incoming payments to the correct internal recipient. For a store, that works a lot like an order number inside a payment reference. The ledger itself does not "know" that the tag represents your order, but your plugin or administrator can use it for matching.

If the tag is missing, the payment may still arrive at the address, but the store will not know which order it belongs to. In that situation, you should not automatically treat any incoming payment as the first matching order you can find. You need manual review: amount, time, sender address, communication with the buyer, and the transaction hash.

Why the validated result matters

Official XRP Ledger documentation distinguishes between a preliminary result and a final result in the validated ledger. For a store, that creates a practical risk: if the system changes the order status too early, the buyer may receive the product before the payment is fully confirmed. If the system waits too long, the customer sees a stuck order and contacts support.

A good setup should strike the right balance. In an automated flow, it is helpful if the plugin records both the fact that a transaction was detected and the final verification status. In a manual flow, it is usually enough for the administrator to see the hash, amount, and time, then make a decision based on that information.

How to handle fees and exact amounts

On XRP Ledger, each transaction destroys a small network fee. For the recipient, that usually does not mean the received amount is reduced by the sender's fee, but the user can still send the wrong amount or choose the wrong asset. That is why your instructions should state the exact XRP amount the order expects, not an approximate one, and separately make clear that the network must be XRP Ledger.

If the plugin converts the store currency into XRP, check how long the quoted amount stays valid. Volatility can create a situation where the buyer places the order at one rate and sends payment later after the rate has changed. If the interface includes an invoice expiration time, use it and explain to the buyer that an expired invoice should be recreated.

Practical Example: Selling a Digital Product for XRP

Let's walk through a scenario that tests almost every critical part of the product: the payment method appears, the buyer receives payment details, the order is saved, the payment is matched, the status changes, and the administrator can see a verification trail. This kind of test is best performed on a separate low-cost product without automatic bulk delivery of access.

Goal and preparation

The goal is to accept a test XRP payment for a digital product and confirm that the WooCommerce order receives the correct status. Before you begin, WordPress, WooCommerce, the main CryptoPay plugin, CodeCanyon XRP Ledger Crypto Payments Support, and a test product should all be active. You also need a wallet capable of sending a small amount of XRP and a way to inspect the transaction in an XRP Ledger explorer.

Verification steps

1. Create a test product with a clear name, such as "XRP Access Test," and assign a small price.
2. Open the site as a customer, add the product to the cart, and proceed to checkout.
3. Select the XRP payment method and confirm that the address, amount, and tag appear if a tag is used.
4. Create the order and keep the instruction page open until the payment is sent.
5. Send XRP from your wallet, carefully checking the network, address, amount, and tag.
6. Wait for verification and open the order in the WooCommerce admin area.
7. Compare the order status, notes, amount, and transaction hash with the details shown in the explorer.

Expected result

After successful verification, the order should move to the status you selected for a paid order, and the history should retain a clear record: the selected payment method, the amount, the time, and ideally the transaction ID. If the product does not write the hash into the order notes, create an internal rule for recording it manually, otherwise disputed payments will be much harder to investigate later.

The detail that often breaks the test

The most common mistake in this kind of test is an incorrect tag or sending from a wallet where the tag is hidden in an extra field. A user may copy the address but miss the tag. That is why you should test not only the ideal scenario, but also a failure scenario: create an order and do not send payment so you can see how it expires; then run a separate test with the wrong amount and check whether the status changes too early.

Verifying the Result After Launch

After one successful test, do not assume the job is finished. The payment method should be verified from the buyer's side, the administrator's side, in email notifications, in caching behavior, and in logs. This is especially important on sites that use optimizers, multi-step checkout flows, custom WooCommerce templates, or third-party status plugins.

What the customer should see

The customer should understand that the order has been created, that payment must be sent on XRP Ledger, that the amount and tag must not change, and that verification will take some time after payment is sent. If you use the WooCommerce thank-you page, make sure the payment details do not disappear there. If the payment details are sent by email, check that line wrapping does not break the address or the tag.

What the administrator should see

In the WooCommerce admin area, check the order status, selected payment method, notes, and any CryptoPay-related fields. It is ideal when the order clearly shows what happened: "awaiting XRP payment," "payment found," "payment confirmed," "amount mismatch," or "manual review required." If the product interface does not provide that level of detail, build the habit of adding the transaction hash to the order note manually.

What to check in logs and caching

If the payment method does not appear or the instructions disappear, check the checkout page cache first. Checkout, cart, and account pages should generally not be cached like ordinary static pages. Also review WooCommerce and CryptoPay logs if they are available. For payment troubleshooting, the log is often more useful than the visual symptom: the user sees "pending," while the log may reveal the real cause - the wrong network, an API failure, server unavailability, or an amount mismatch.

Security, Privacy, and Operational Limits

Crypto payments do not make a store automatically safer. They reduce reliance on card processors, but they introduce different risks: irreversible transfers, public transaction data, user error, the need to protect wallet access, and the complexity of handling refunds. That is why the setup should stay conservative.

Do not store unnecessary secrets in WordPress

If the product needs an API key, token, or private wallet-related data, store only what is truly necessary. Do not paste a seed phrase or private key into fields unless the product explicitly requires it and clearly explains why. For most merchant scenarios, it is better when the site can receive and verify payments without gaining the ability to move all funds on its own.

Do not promise instant fulfillment in every case

Even if XRP Ledger usually confirms transactions quickly, your public store copy should not promise absolute instant delivery. It is safer to say that the order updates after the payment is detected and verified. That protects your support team when an external node is delayed, a wallet behaves incorrectly, the tag is wrong, or the API is temporarily unavailable.

Be careful with automatic access

If the product is digital and WooCommerce grants access automatically after the order reaches "completed," check which status the plugin actually sets. In some cases, it is safer to move the order to processing first and only grant access after an extra review. That is less convenient, but it reduces risk when the payment is partial or the match is disputed.

Logs, Notifications, and Monitoring After the First Payments

Once the payment method is live, the administrator's work is not over. The first real payments deserve closer monitoring than ordinary card orders because you are validating not only the plugin, but also how customers behave. Someone may send payment from an exchange, from a wallet where the tag field is not obvious, from an app that rounds the amount, or after the invoice has already expired. If you do not watch logs and orders during the first few days, those cases quickly turn into scattered support emails.

Ideally, the team should follow one shared monitoring routine. It does not need to be complex. It is enough to know where to look for new orders, where payment notes appear, who decides whether to credit a payment manually, and how the transaction hash is recorded. The simpler the rule, the lower the chance that one employee credits a disputed payment and another later has no idea why the order status changed.

Which events are worth recording

If CryptoPay or the XRP add-on maintains a separate log, enable it at least during testing and the first live payments. A log is useful not only when something fails. It also shows the normal path: order created, invoice generated, payment found, verification passed, status changed. Once you have seen the healthy flow a few times, diagnosing a failure becomes easier because you know exactly where the chain broke.

For manual order notes, use a short but consistent format. For example: "XRP payment checked manually: amount matches, tag matches, hash ...". Even if your internal admin instructions are written in another language, the hash itself should remain unchanged and complete. Do not place private wallet data, seed phrases, internal API tokens, or unnecessary customer correspondence into the order note.

• Record the transaction hash if it is not saved automatically.
• Note whether the amount matched the order and how that was verified.
• State whether the tag was correct or whether manual review was required.
• Save the reason for any manual status change if the order did not update on its own.
• Do not store secrets in the order if they are not needed for customer support.

Customer notifications

Test WooCommerce emails in three states: order created and awaiting payment, order paid, and order pending manual review. If the post-checkout email does not include the payment details, the customer may close the payment page and lose the instructions. If the payment confirmation email arrives too early, the buyer may assume everything is complete even though the transaction is not yet matched. If there is no email when something goes wrong, support volume increases.

You do not need to rewrite every email template. Sometimes it is enough to add one clear line to the order-page instructions: "If you already sent XRP but your order has not updated, save the transaction hash and contact support." That reduces low-information tickets. Instead of "I paid," support receives the hash, amount, and order number, which makes verification much faster.

Checks after a price or exchange-rate change

If the XRP amount is calculated from the store currency, place a new test order after any product price or exchange-rate change. Problems often appear not at installation time, but after updates to discounts, coupons, taxes, or currency settings. For example, the product price changes, but a cached payment page still shows the old amount. Or a coupon reduces the order total, but the payment instruction was generated before the recalculation.

Check not only the final product amount, but also shipping, taxes, coupons, and fees if they participate in the calculation. For a digital product without shipping, the scenario is simpler. For a physical store, payment can depend on the selected shipping zone, tax setup, and the buyer's country. If the XRP method should work only for specific products or countries, test those conditions with separate orders.

Mini-checklist for the first live payments

It is a good idea to review the first few payments manually even when automation is enabled. That is not a sign of distrust in the plugin - it is a normal part of launching a payment method. You are checking how real buyers read the instructions, how quickly orders update, whether the theme breaks the payment block, and whether the same questions keep coming up.

1. Open each new XRP order and confirm that the payment method is clearly listed.
2. Compare the order total and the amount of the incoming transaction.
3. Check the tag if your workflow uses one.
4. Open the hash in a trusted explorer or another available verification method.
5. Make sure the order status changed as expected.
6. Confirm that the correct email was sent to the customer.
7. Record anything that had to be handled manually in the order notes.

After several successful payments, you will have a better sense of which checks can be reserved for disputed cases only. But it is not wise to remove manual oversight entirely: crypto payments are irreversible, and support should always have a recovery path when the user makes a mistake.

How to Prepare the Product Page and Support Team for a New Payment Method

A payment method affects more than the checkout page. If you accept XRP, it helps to mention that before the customer starts checkout. You do not need to turn the product page into technical documentation, but a short note is useful: payment is available through XRP Ledger, the transfer may require a tag, and the order updates after verification. That way, the customer does not encounter an unfamiliar payment method only at the final step.

The support team also needs a short instruction. It should answer four questions: which details to request from the customer, where to verify the hash, who is allowed to change an order status manually, and what to do when the amount does not match. If those rules are not documented, every disputed payment will be handled from scratch, which increases the risk of mistakes.

Customer-facing copy without overload

Good payment copy stays calm: "Choose XRP payment, send the exact amount to the address shown, and be sure to include the tag if one is displayed. After the payment is verified, your order will update automatically or be reviewed by support." That kind of text does not promise instant delivery, does not bury the user in technical terms, and does not expose unnecessary details about the plugin's internal logic.

Do not claim that crypto payment is "the safest" or "error-proof." That is not true in practice. Security depends on the customer's wallet, the correctness of the address, the tag, the verification process, and the behavior of your site. It is better to explain honestly that the customer needs to double-check the payment details carefully.

Support instructions

Your internal support guide can be more technical. Specify where to find orders paid with the XRP method, how to filter them by status, which notes the plugin adds, what to do with a payment that arrived without a tag, and where to store the transaction verification link. If multiple people handle support, do not allow manual status changes without recording the reason. That keeps the process disciplined and helps if the customer follows up later.

For disputed cases, it helps to keep a response template ready. For example: "We can see your order, but to verify the XRP payment we need the transaction hash and the transfer amount. If you sent the transfer from an exchange, please confirm whether a destination tag was included." That kind of reply does not blame the customer and immediately asks for the details that are actually needed for verification.

When to disable the method temporarily

Sometimes the best way to protect the store is to disable XRP payments for a while. That makes sense if several orders in a row get stuck for no clear reason, the verification API is unavailable, the method stops displaying correctly after a WooCommerce update, the theme breaks the payment-details block, or the support team can no longer keep up with disputed payments. Disabling the method in WooCommerce > Settings > Payments is usually safer than continuing to accept new payments in an unstable state.

After fixing the root cause, re-enable the method only after running a test order. Do not check only the settings screen. You need to walk the customer path again: choose the method, see the payment details, send a test payment or simulate the flow, verify the order status, and confirm the email behavior.

A Small Interface Improvement Without Editing the Plugin

If the payment page shows the address, amount, and tag but they visually blend into the surrounding text, you can carefully improve the block with theme CSS or the Additional CSS area. This does not modify the plugin code and is easy to roll back. Use this approach only after checking the real classes on your site, because checkout markup varies across themes.

Below is a conservative example. It does not depend on the product's internal PHP hooks and does not change the payment logic. Before using it, replace the selectors with the ones you actually see in the browser inspector.

/* Improves the readability of the XRP payment block on the order page.
   Add this to a child theme or the theme's "Additional CSS" section. */
.woocommerce-checkout .cryptopay-xrp-box,
.woocommerce-order .cryptopay-xrp-box {
  border: 1px solid #d8e2f0;
  background: #f7fbff;
  padding: 16px;
  border-radius: 8px;
  margin-top: 12px;
}

.woocommerce-checkout .cryptopay-xrp-box code,
.woocommerce-order .cryptopay-xrp-box code {
  display: inline-block;
  padding: 3px 6px;
  background: #ffffff;
  border: 1px solid #dfe7f3;
  border-radius: 4px;
  word-break: break-all;
}

The check is simple: open the checkout page, select the XRP method, and make sure the address and tag are easier to spot without breaking the payment button, WooCommerce fields, or theme text. Rolling back is just as simple - remove this CSS. Do not add JavaScript to auto-fill the address or amount unless you are fully confident in the markup: for a payment block, less magic and more verifiability is usually the safer choice.

Troubleshooting: Why an XRP Payment Was Not Credited

Crypto payment issues are easiest to debug as a chain: the order was created, the instructions were shown, the transaction was sent, the transaction was detected, the result was validated, the amount and tag matched, and the order status changed. If you skip the sequence, it becomes easy to confuse an interface problem with a blockchain problem.

The payment method does not appear at checkout

Symptom: the plugin is active in the admin area, but the customer does not see the XRP payment option. Possible causes include the parent CryptoPay plugin not being active, the gateway itself not being enabled, required fields not being filled in, the method being restricted by currency or country, checkout caching, or a theme overriding the payment template.

Check WooCommerce > Settings > Payments, the method status, CryptoPay settings, and the checkout page without cache. If the method appears in a default theme but disappears in the live theme, look for a template or builder conflict.

The user sent XRP, but the order stayed pending

Symptom: the transaction exists in the explorer, but the order status does not change. Check the amount, recipient address, destination tag, send time, and invoice expiration. If the tag is missing or does not match, automatic matching may be impossible. In that case, it is safer not to change the status without manual review.

The amount does not match the expected value

Symptom: the order expects one amount, but the incoming payment shows another. The cause may be a bad conversion, an expired invoice, a customer manually changing the amount, or using the wrong asset. Check when the order was created, which rate was used, whether there is an expiration period, and how the plugin handles partial payments. If the rules are not clear, leave the order pending and contact the customer.

The status changed, but access was not granted

Symptom: the payment was confirmed, but the buyer did not receive the file, email, or access. At that point, the issue may no longer be the XRP add-on itself, but the interaction between WooCommerce statuses, digital goods, email, and a membership plugin. Check which status was assigned to the order and which actions are tied to that status. Sometimes you need to adjust the access rule or avoid treating processing as final payment for a specific product.

The payment was credited twice or a duplicate order appeared

Symptom: one user ended up with two paid orders or repeated fulfillment. This can happen after a repeated send, a mistaken manual status edit, or incorrect handling during re-verification. Compare the transaction hash: one transaction should not confirm multiple independent orders unless that behavior is explicitly part of your manual procedure. If anything looks questionable, pause automatic delivery and inspect the log.

When CodeCanyon XRP Ledger Crypto Payments Support Is the Right Choice

This product is worth using if you specifically need XRP Ledger support inside an existing CryptoPay setup and are prepared to configure the payment flow as an engineering chain rather than just turning on a button. On the store side, WooCommerce orders, statuses, customer instructions, caching, logs, and a manual process for disputed payments all need to be verified.

If you need a multi-currency checkout with a large list of supported coins, an aggregator may be more convenient. If you need self-hosted Bitcoin processing, BTCPay Server is the more logical place to look. But if the goal is to add XRP payments to a CryptoPay setup you already use, CodeCanyon XRP Ledger Crypto Payments Support can be a precise and lightweight solution.

Before exposing it to real customers, run the practical test from this guide, review the order in the admin area, and make sure the support team knows what to do when the amount or tag is wrong. After that, you can get the WordPress version and move on to a careful setup on your own site.