WooCommerce Custom Payment Gateway Pro - WordPress Plugin

How to Configure WooCommerce Custom Payment Gateway Pro for Manual Payment Methods

WooCommerce Custom Payment Gateway Pro is useful not as just another card processor, but as a practical tool for cases where a store needs its own manual payment method in WooCommerce: a bank transfer, an invoice for a B2B customer, a payment link, a local wallet, pay on pickup, manual crypto payment instructions, or any other scenario where the order is created in the store and payment confirmation is checked separately.

In this guide, we will look at how to approach setup without putting checkout at risk: what to verify before installation, where to enable the payment method, which fields and messages to show the customer, which order status to choose, how to test the result in both classic and block-based checkout, when to use a post-checkout API request, and why debug mode should be enabled before a public launch.

This guide is intended for a store owner, webmaster, or developer who already understands the basic WooCommerce workflow but does not want to build a custom payment gateway from scratch. It does not cover buying the plugin or bypassing its license. The focus is strictly on practical configuration of an already installed product, verifying the result, and troubleshooting common issues.

What Problem This Plugin Solves in a Real Store

The main value of this plugin is not that it replaces Stripe, PayPal, or bank acquiring. It solves a different problem: adding a controlled payment method to WooCommerce where the store defines the rules, collects the required data, and chooses the order status after checkout. That matters most for stores that accept payments through more than standard automated gateways.

The official WPRuby page clearly states that the product does not process financial transactions or accept payments on its own. That is not a weakness, but a boundary of use. The plugin is responsible for the form, instructions, extra fields, data transfer, and order behavior inside WooCommerce. The money itself still moves through a bank, a payment link, an invoice, a local wallet, a cash counter, an external service, or manual review by a manager.

This approach is useful wherever payments cannot be fully automated, or where automation is not worth the cost. For example, a B2B store may take invoice-based orders and ask the customer to include the order number with the payment. A local store may offer a "Pay on Pickup" option and show the address, business hours, contact phone number, and a comment field. A store using a payment link may show a button to an external service and ask the customer to return to the order with the transaction number or upload proof of payment.

How a Manual Gateway Differs from Standard Online Payment Processing

An automated payment gateway usually confirms the transaction on its own, reports the result back to WooCommerce, and moves the order into the appropriate status. A manual gateway works differently. It shows instructions, collects data, and leaves payment verification to the store owner or an external system. That is why setup is not just about the method name and description, but the full path: what the customer sees, what information they leave behind, where the order lands, whether the team gets notified, and how a manager knows the payment can be approved.

If the store accepts standard card payments through a ready-made acquiring integration, WooCommerce Custom Payment Gateway Pro should not replace secure payment processing. But if you need to fit a manual process neatly into checkout and avoid pushing customers into messy back-and-forth communication, the plugin becomes a useful layer between the order and the actual payment procedure.

Which Scenarios Fit Custom Payment Gateway Pro Especially Well

Based on the product page and related WPRuby pages, the plugin is designed for several common real-world scenarios. It helps to understand them before setup, because each one calls for a different set of fields and a different order status:

• Bank transfer with instructions, account details, an invoice link, and a field for the payment reference.
• Invoice payment for B2B customers, where you may need a tax ID, purchase order number, accounting contact, or a payment note.
• A manual payment link, where the customer opens Wise, Revolut, PayPal.me, a Stripe Payment Link, or another external URL, then returns and submits confirmation.
• Uploading proof of payment, when the team needs a receipt, screenshot, PDF, or bank confirmation.
• Pay on pickup, where it is important to show the address, order hold policy, and contact details.
• A manual crypto payment flow, where the store shows the wallet address, network, QR code, or instructions, and the customer leaves the transaction hash.

In all of these cases, the key question is the same: what data does the store need to safely match the order to the payment. If you answer that before setup, the plugin will not turn into a pile of random fields. It will become a clear working process.

Who This Payment Workflow Fits and When It Is Unnecessary

This plugin is best suited for stores where some payments follow rules that differ from standard acquiring flows. That is not limited to small businesses. Manual payments are common in wholesale orders, custom supply arrangements, local services, international transfers, pre-approved orders, high-ticket sales, and projects where the customer submits the order first and a manager confirms payment afterward.

WooCommerce Custom Payment Gateway Pro can also be useful for agencies and developers who regularly add non-standard checkout methods for clients. Instead of building a separate payment gateway class every time, they can assemble the method through settings: define the name, description, icon, form, order status, API request, and debug mode. That does not replace development for complex integrations, but it covers a large range of manual scenarios without needing a separate plugin for every store.

When the Plugin Is a Good Choice

This product is worth considering if at least one of these points applies:

• The customer needs to see detailed payment instructions directly at checkout instead of receiving them manually after placing the order.
• The store needs to collect a transaction number, bank reference, comment, file, or additional billing details.
• You need to create several similar payment methods for different scenarios, regions, customer types, or external services.
• After checkout, the order should receive a preselected status so the team knows manual verification is required.
• You need to send order data to an external service through POST or GET, but without building a full payment gateway integration.
• You want to test the method for admins first without showing it to all customers.

When Another Approach Is Better

This plugin is not a replacement for a full payment processor if you need automatic card authorization, stored payment tokens, refunds from WooCommerce, subscriptions with automatic rebilling, built-in fraud screening, or a full PCI-compliant card processing environment. For those tasks, it is better to use the official gateway from the provider or build a dedicated integration based on the provider's documentation.

You should also be careful with API-driven scenarios. WPRuby's documentation explains that API requests can be used to send payment data to an external system, but it does not promise a universal integration with any payment provider out of the box. If the external service requires signatures, tokens, complex callback events, idempotency, error handling, and separate statuses, a form-based setup may be only a first prototype, not the final financial integration.

Practical rule of thumb: if the customer enters sensitive card data on your site, use the provider's dedicated gateway. If the customer receives instructions, a link, a QR code, or leaves confirmation for manual review, WooCommerce Custom Payment Gateway Pro is a much better fit.

What to Check Before Installing on a Live Site

Preparation matters not because installation is difficult, but because the payment method lives in a critical part of the store. A checkout mistake can immediately affect sales, email notifications, order statuses, inventory, and the work of your team. That is why it is worth doing a short but focused review before installation.

WooCommerce Compatibility and Checkout Type

The WPRuby product page states support for WooCommerce Blocks. That is important because modern stores may use block-based cart and checkout pages instead of the classic checkout page. At the same time, reviews and changelogs for similar plugins show that block compatibility is often where problems appear in this category. So do not stop at checking the admin panel. Create a test product, open the actual checkout page, and confirm that the payment method appears in the exact checkout flow your site uses.

If you have an older theme, a customized checkout, a builder-based page, or an extra custom fields plugin, test the full journey: cart, shipping selection, manual payment method selection, field completion, order placement, the Thank You page, the order in the admin panel, and email notifications.

Order Statuses and Emails

The most common trap with manual payments is the wrong post-checkout status. If the order stays in a state where WooCommerce does not send the expected emails or the team does not see it in the right work queue, the customer may never receive the instructions and the manager may miss the payment. In WPRuby's troubleshooting documentation, they specifically note that missing email notifications may require changing Order Status After The Checkout to Processing. But that is not a universal rule for every store.

For manual review, it is often more logical to use a status that means "awaiting payment" or "on hold" rather than "paid." If the status moves the order into processing too early, your warehouse or team may start fulfillment before the money is actually confirmed. So before launch, decide who checks the payment, where that happens, which emails should go out, and when the order can truly be treated as ready for fulfillment.

Files, Personal Data, and Payment Confirmations

If you plan to use file upload or a payment reference field, decide in advance what data it is acceptable to collect. A receipt, screenshot, transfer number, transaction hash, or invoice number may be helpful for reconciliation, but there is no reason to request extra personal data. The less sensitive information stored with the order, the easier it is to maintain security and privacy.

Be especially careful with fields that let the user upload a file. Make the upload required only where the file is genuinely necessary to reconcile the payment, and make sure your managers understand that a file does not prove payment by itself. It only helps locate the payment in an external system.

Test Environment and Rollback Plan

Before enabling the plugin on live checkout, it is best to test it on a staging copy or at least in a mode that regular customers cannot see. WooCommerce Custom Payment Gateway Pro includes a debug mode that activates the gateway only for administrators. That is a convenient way to test the method on the live site without exposing a new payment option to all customers.

Your rollback plan should be simple: disable the new gateway, clear the checkout page cache, restore the previous order status, and confirm that the standard payment methods work again. Do not change several payment plugins, the checkout theme, and email settings all at once. If something breaks, you will not know which change caused it.

Installation and Initial Verification in WooCommerce

The official WPRuby documentation describes the standard installation methods: through the WordPress plugin directory for the free version, by uploading the ZIP file in the admin panel for the Pro archive, or through FTP. For most store owners, the safer choice is the WordPress admin panel, without touching files manually. FTP installation is only necessary when the admin panel cannot upload the archive or the site is managed through a separate deployment workflow.

Basic Installation Through the Admin Panel

If you already have the plugin archive locally, the general path looks like this:

1. Open Plugins in the WordPress admin panel and go to add a new plugin.
2. Select the ZIP upload option and choose the file woocommerce-custom-payment-gateway-pro.zip.
3. Install and activate the plugin.
4. Go to WooCommerce - Settings - Payments and find the custom payment gateway settings.
5. Do not enable the public method for all customers until you have created a test gateway and verified an order.

After activation, do not judge success only by seeing the plugin in the list. For a payment extension, three checks matter: the method exists in WooCommerce settings, the method appears at checkout under the right conditions, and after checkout the order receives the expected status and data.

Initial Test Without Publishing It to Customers

Start with a minimal gateway. Give it a neutral name, such as "Test Manual Payment," add a short customer-facing message, and choose a status that does not trigger fulfillment too early. If you use debug mode, make sure only the administrator can see the method. Then create a low-cost test product or use an existing product with test shipping.

Go through checkout as a customer. Confirm that the user sees clear text, does not run into empty technical fields, and understands what to do after clicking the place order button. Then open the order in the admin panel and check whether all submitted data is there. If you added a file, verify where it appears and whether the manager has enough access to review it.

Quick checkpoint after installation: the new payment method should appear only where you expect it, the text should make sense to the customer, and the WooCommerce order should receive the correct status and data for manual reconciliation.

Team Workflow: Who Verifies the Payment and Where They See the Data

A manual gateway should not be treated as just a checkout setting. Once the order is placed, internal work begins: someone has to verify the payment, match it to the order, leave a note, update the status, and contact the customer if needed. If that process is not defined, even a perfectly configured form will not prevent delays.

Before the final launch, create a short operating instruction for your team. It can stay internal and does not need to be public. It should clearly explain which orders go to manual review, which fields to check, which files to open, where to verify the payment in the external system, and which status to set after confirmation. For a small store, that may be one responsible manager. For a B2B or wholesale store, it is better to split responsibilities: the manager verifies the order, accounting confirms the payment, and the warehouse starts fulfillment only after the status changes.

How to Tie Gateway Fields to Manager Actions

Every field you add in the form builder should have an owner in the process. If the customer enters a transaction number, who checks it? If they upload a file, where is the manager supposed to open it? If they leave an accounting contact, who reaches out to that person? Without this mapping, fields quickly turn into a data archive that nobody actually uses.

A good workflow looks like this:

• The customer selects the manual payment method and sees the instructions.
• The customer submits only the information needed for reconciliation.
• WooCommerce creates the order in a manual review status.
• The manager opens the order and sees the selected gateway and form data.
• The payment is verified in the external system or against the bank statement.
• After confirmation, the manager changes the status and leaves a note in the order.

This may sound obvious, but it is exactly what helps you spot unnecessary fields. If you cannot say who uses a specific field, it probably does not belong in checkout.

What Notes to Leave on the Order

An order note is the simplest way to preserve the context of manual verification. After reconciliation, the manager can record where the payment was checked, which reference matched, and what happened next. There is no need to write secret data, full account details, tokens, or internal passwords into the note. A short internal message such as "Payment reconciled using the checkout field reference, order moved to processing" is enough.

If the payment is not found, the note should help the next person understand the situation: "Reference not found on the statement, customer asked to provide confirmation." This is especially important if the store runs in shifts or multiple managers handle orders.

How to Avoid Breaking Warehouse and Fulfillment Workflows

The manual payment status should align with your warehouse process. If your warehouse integration pulls in every order marked Processing, then moving manual payments into that status may start picking and packing before the money is confirmed. If the warehouse only watches Completed, the order may get stuck and never move into work even after payment. So after configuring the gateway, review not just email, but all neighboring processes too: warehouse, CRM, exports, manager alerts, accounting, and analytics.

For the first orders after launch, it is useful to keep a manual checklist. Track the order number, selected payment method, reference, status after checkout, verification result, new status, and the manager's comment. After a few days, that list will show where people make mistakes most often: in the customer instructions, the status, the field label, or the external system response.

Detailed Payment Method Configuration After Installation

Configuring WooCommerce Custom Payment Gateway Pro comes down to one question: what should happen between the moment the payment method is selected and the moment the order is manually verified. Do not try to fill out every field just in case. It is better to build the gateway like a compact instruction for the customer and the manager: name, icon, message, form, status, notifications, API transfer, and debugging.

Name, Description, and Icon at Checkout

Method Title is the name the customer sees among the payment options. It should be short and precise. "Bank Transfer," "Pay by Invoice," "Pay on Pickup," or "Payment Link" reads much better than internal labels like "Manual Gateway 2." If you have several methods, add enough distinction to the name, but do not overload it with conditions.

Gateway Icon helps visually separate the payment method, but it should be used carefully. Use a small, clear icon or the logo of your own payment method if you have the right to use it. Do not insert heavy images, do not use someone else's watermarked artwork, and do not rely on the icon alone. The customer should understand the method from the text.

Customer Message and Post-Checkout Note

Customer Message is shown to the customer at checkout. This is the main piece of text that should remove uncertainty. A good message answers three questions: where to pay, what to include in the payment note or reference, and what happens after the order is placed. A bad message sounds like "Pay manually" and leaves the customer hunting for instructions in email.

Customer Note is useful after checkout, once the order already exists. There you can repeat the key instruction, provide the address, remind the customer about the payment deadline, or explain that a manager will verify the payment manually. Do not overload these fields with long legal text. For details, it is better to link to a payment terms page and keep checkout focused on a short practical instruction.

Order Status After Checkout

Order Status After The Checkout is the most important setting from an operational perspective. The status affects emails, warehouse handling, order visibility for the team, and downstream automation. With manual payments, stores often choose a status that shows the order has been created but the payment still needs verification. If your process allows the order to move directly into fulfillment, the status should reflect that reality.

Do not copy a status from someone else's tutorial. Verify your own chain: which email goes to the customer, who sees the order, whether stock is reduced, whether the order goes into exports, and whether CRM or warehouse integrations are triggered. If emails do not send during testing, WPRuby documentation suggests checking the status and choosing Processing if needed, but that decision still has to match your actual manual payment review flow.

How to Choose the Right Status Without Mistakes

For bank transfers or invoice payments, a status that does not imply final payment is usually safer. For pay on pickup, you can choose a status that fits your logistics flow. For an external payment link, the right choice depends on whether the external service confirms payment automatically. If it does not, do not move the order into a fully paid status just because the customer clicked the place order button.

Form Fields: What to Ask the Customer

One of the strong points of the Pro version is the form builder. The product page and the WordPress directory listing for the related free version mention different field types: text, textarea, checkbox, radio, select, email, date, time, URL, currency, number, phone, instructions, and others. In practical configuration, what matters more than the number of field types is how precisely you ask for the information.

For a bank transfer, a field like "Payment Order Number" or "Payment Reference" is usually enough, plus proof of payment upload if needed. For invoice payment, you can add "Purchase Order Number" and "Accounting Contact." For a payment link, a "Transaction Number" field and a short note are often enough. For local pickup, a comment about arrival time is more useful than extra finance-related fields.

Make fields required only for truly critical data. If a field is required, the customer should understand where to get the value. For example, you cannot require a "transaction number" before payment if the customer has not even opened the payment link yet. In that case, it is better to make the field optional or explain the sequence clearly.

API Request After Checkout

The plugin lets you enable an API request after checkout, specify a URL, choose the request method, pass WooCommerce API parameters and extra API parameters, and use JSON format for POST requests. That is useful for sending the order to a CRM, a reconciliation spreadsheet, an internal system, a lightweight accounting tool, or an intermediate handler.

But having API functionality does not mean it is a ready-made universal integration with any payment provider. If the external service requires complex authorization, callback handling, response signatures, or separate status checks, the setup should be designed alongside that service's documentation. Handle secret tokens carefully and never expose them in public hints, email text, or fields visible to the customer.

Debug Mode Before Public Launch

Enable Debug Mode, according to WPRuby documentation, activates the gateway only for the administrator. This is one of the most useful modes before launch because it lets you test checkout on the live site without the risk of a customer choosing an unfinished payment method. Turn on debug mode, place a test order, and verify emails, the order, fields, status, and API transfer. Then disable the mode and test the method again as a regular user.

Multiple Gateways: How to Keep Checkout from Becoming a Mess

The official WPRuby documentation shows a separate screen for adding multiple gateways: you go to the custom payment gateways settings, enter a new name, and save changes, after which the gateway appears in the table and can be configured or deleted. That capability is useful, but it is also what most often turns checkout into a cluttered mess when the structure is not thought through.

You need multiple payment methods only when the customer is genuinely choosing between different processes. "Bank Transfer for Individuals" and "Pay by Invoice for Companies" may differ in instructions, fields, and status. "Pay on Pickup" differs from "Payment Link" not just in name, but in what the customer does after checkout. If the only difference is the wording of the payment details, sometimes a single gateway with clear instructions is enough.

How to Group Manual Methods

Start not with the number of gateways, but with a map of your business processes. For each method, answer these questions:

• Who chooses this payment method and why.
• What information the customer needs to provide.
• Which order status is needed immediately after checkout.
• Who on the team verifies the payment and where they see the data.
• Whether the data needs to be sent to an external service.
• What happens if the customer selects the method but never pays.

If two methods produce the same answers, they may belong together. If the answers differ, a separate gateway is justified. This approach reduces mistakes and helps you write clearer instructions without duplication.

Ordering and Naming at Checkout

The customer should not have to decode the store's internal accounting logic. Payment method names should be short, and the differences should be obvious. "Bank Transfer" and "Pay by Invoice for Companies" are better than "Manual Payment 1" and "Manual Payment 2." If manual methods appear next to automated ones, describe them especially clearly so the customer does not expect instant capture or automatic confirmation.

For larger stores, it is often best to start with one or two manual gateways and add the rest after testing. Too many payment options increase support questions and complicate analytics. The plugin supports an unlimited number of gateways, but the business process usually benefits from restraint.

API, Return URL, and Safe Data Transfer to an External System

WPRuby's documentation covers two important technical directions: adding custom parameters to API data through the custom_payment_gateways_api_data filter and processing the returned result through the custom_payment_process_returned_result action. This is already developer territory, but even store owners benefit from understanding the mechanics so they do not expect the settings to do something they cannot do.

An API request after checkout is usually needed not for instant payment capture, but for sending context: order number, amount, customer name, email, city, phone number, selected method, custom fields, and extra parameters. The external system may create a request, record the order, assign a task to a manager, or prepare a link for manual verification.

What You Can Send Through API Parameters

WPRuby's documentation describes a key/value parameter approach: you add a key, and the plugin inserts the value from the order. For example, the key total_amount may map to the order total. This works well for simple external systems that just need understandable fields such as order_id, total, customer_email, and payment_reference.

But the closer you get to real payment processing, the more requirements appear: request signing, response verification, protection against duplicate submissions, handling network failures, logging, and secure token storage. If the external system makes decisions about payment, one simple POST request may not be enough.

Return URL and Status Changes After the Provider Response

WPRuby describes an example return URL such as https://yourdomain.com/?wc-api=wc_custom_payment_gateway and the custom_payment_process_returned_result action for result handling. This is useful when an external service can send the user or a notification back to the site. However, the parameter keys and response logic depend on the specific provider, so they cannot be guessed.

If you are connecting an external service, start by opening the provider's documentation and finding out which parameters it sends for successful and failed payments. Then a developer should carefully map those parameters to WooCommerce order statuses. Do not treat the documentation example as a ready-made solution for every service. It shows the principle, but it does not replace an integration specification.

Safe Snippet for an Extra Parameter

If you need to add a non-secret internal parameter to the API request, you can use the official filter from WPRuby's documentation. The example below adds a tracking identifier based on the order ID. You can insert it through Code Snippets or into a child theme file if you understand how to roll the change back.

<?php
add_filter( 'custom_payment_gateways_api_data', 'jf_add_gateway_tracking_parameter', 10, 2 );

function jf_add_gateway_tracking_parameter( $wc_parameters, $order_id ) {
    // Internal parameter for matching the order in the external system.
    // Do not use secret keys here unless you fully understand the provider requirements.
    $wc_parameters['store_order_marker'] = 'order_' . absint( $order_id );

    return $wc_parameters;
}

After adding the snippet, place a test order in debug mode and check the external system log. If the parameter does not arrive, disable the snippet and go back to the basic API field configuration. If the external service requires a signature or token, do not extend this example blindly. It is better to hand the integration off to a developer.

Rollback: disable the snippet in Code Snippets or remove it from the child theme, then place another test order. The gateway configuration in WooCommerce should remain intact.

Practical Example: Payment Link with Payment Confirmation

Let us walk through a scenario that shows the plugin's strengths particularly well: the store wants to accept payment through an external payment link. The customer selects the method at checkout, opens the link, pays in the external service, returns to the order, and submits the transaction number or uploads proof of payment. The team verifies the payment and manually moves the order forward.

Goal

The goal is to create a checkout method called "Pay by Payment Link" that does not mislead the customer. It should clearly explain that payment happens in an external service, while WooCommerce creates the order and stores the data needed for manual reconciliation.

Preparation

Before setup, you should already have a working payment link or provider page, a clear customer instruction, a decision on the order status after checkout, a list of data needed for reconciliation, and a test product. If you plan to use a QR code, make sure the image actually leads to the intended payment flow and test it on a phone before publishing.

Setup Steps

1. Create a new gateway and name it "Pay by Payment Link."
2. In Customer Message, explain that the customer must open the link, complete payment in the external service, and provide the transaction number during checkout.
3. Add a button or link to the external payment service in the instructions, if your setup supports that.
4. Add a "Transaction Number" or "Payment Comment" field. Make it required only if the customer receives that number before submitting the order.
5. Add optional proof upload if it genuinely helps your managers.
6. Choose an order status that means manual review, not automatic payment confirmation.
7. Enable debug mode and place a test order as an administrator.
8. Check the order in the admin panel: status, form data, file, notes, emails, and payment method visibility.

Verifying the Result

A successful setup looks like this: the customer sees the payment method with a clear name, reads a short instruction, does not get lost at the external link, returns to the order, and leaves the data needed for reconciliation. In the admin panel, the manager sees the selected method, the transaction number, the file if one was uploaded, and a status that does not push the order into fulfillment before verification.

A Common Detail That Breaks the Flow

Do not require the transaction number before the customer has had a chance to receive it. If the link opens in a new window and the number appears only after payment, the field should either stay optional or be replaced with something like "Payment Comment." Another option is to create the order first and request confirmation later through follow-up communication. The right choice depends on how the external service works.

Also, do not name the method "Pay Now" if the actual confirmation will be manual. It is more honest to label it "Pay by Payment Link" or "Manual Payment Link Review." That reduces disputes when the customer assumes WooCommerce has already confirmed the payment automatically.

How to Verify the Result After Setup

Result verification should mirror the real path of both the customer and the manager. It is not enough to click Save Changes in the settings and see the gateway in the list. A payment method lives in several places at once: checkout, WooCommerce blocks, the order page, email notifications, the admin panel, exports, the API, and external systems.

Customer-Side Testing

Open the site in a private window or log in as a test customer. Add a product to the cart, go to checkout, choose the new payment method, and read the text through the eyes of someone seeing it for the first time. Every step should be clear without contacting support.

Check that the form fields do not conflict with the theme: labels should not overlap, required fields should be clearly marked, file upload should work, long instructions should not break the mobile view, and the place order button should remain visible. If the site uses WooCommerce blocks, test the block-based checkout page separately, not just the classic shortcode checkout.

Order and Email Testing

After checkout, open the order in the admin panel and answer these questions:

• Does the order status match a manual review flow?
• Is the payment method displayed with a clear name?
• Can the manager access the custom field data?
• Can the proof file, if used, be opened safely and without unnecessary access?
• Does the customer email contain enough information, or at least not contradict the checkout instructions?
• Does the administrator or manager receive a notification if the workflow requires one?

If emails are not being sent, first check the order status, then your general WordPress mail delivery, WooCommerce email settings, and the logs from your mail service. Do not change the payment plugin, SMTP setup, and email templates all at once, or it will be much harder to isolate the cause.

API and External System Testing

If the API request is enabled, test it separately from the visual checkout experience. First confirm that the order is created correctly without the API. Then enable the transfer and check that the external service receives the expected keys and values. If JSON is used, make sure the receiving side actually expects JSON rather than standard form data.

For external systems, it helps to keep a separate test-order log: order number, time, selected gateway, status, sent parameters, service response, and manager action. A log like that quickly reveals where the chain breaks: in checkout, in the API, in the external system, or during manual verification.

Security, Speed, and Checkout Clarity for Manual Payments

A manual payment method should not make checkout worse just because it is easier to configure than a full gateway. The customer sees the payment block at the exact moment when cart abandonment risk is highest. If the instructions are long, the fields are unclear, a file is required for no good reason, the icon feels out of place, and the order status triggers the wrong emails, the store gets friction instead of flexibility.

Data and Secret Handling

Do not ask the customer to enter anything that is not needed for reconciliation. A transaction number, bank reference, or comment field is usually safe enough as long as it does not contain secrets. But there is no reason to collect full card data, PINs, wallet passwords, one-time codes, private keys, or internal tokens. If the external payment service requires a secret key, it should live in a protected setting or on the integration side, not in checkout text and not in a customer-facing field.

If you enable file upload, explain exactly what can be uploaded. For many stores, a screenshot or PDF confirmation is enough, but the manager still needs to verify the payment in the external system. A file is not the same as payment. It is only a clue that helps find the payment. Internally, agree on how long such confirmations should be stored and who is allowed to access them in the admin panel.

Checkout Speed and Caching

The payment block should not add heavy images, long external scripts, or unstable elements. If you need a gateway icon, use a lightweight file with a predictable URL. If you show a QR code, check its size and readability, but do not insert an oversized image. Checkout is not the place for a heavy promotional banner.

Caching on the checkout page needs special care. Most stores exclude the cart and checkout from aggressive cache rules, but JavaScript optimizers, minification, and deferred loading can still break fields or payment method updates. If the gateway appears inconsistently after you enable it, fields disappear, or the form behaves unpredictably, temporarily disable optimization for checkout only and test again. That helps separate a plugin issue from a cache issue.

Instruction Text and Customer Trust

The customer should understand what happens to both the money and the order. If the method is manual, say so directly. Do not promise instant confirmation if a manager checks the payment later. Do not call the method "card payment" if it leads to an external payment link. Avoid vague wording like "we will contact you" when you can give the customer an exact next step.

A good checkout instruction usually has three short parts: what to select, what to do after selecting it, and how the store will confirm the order. For example: "Open the payment link, pay for the order in the external service, and enter the transaction number. We will verify the payment and update the order status." Text like that reduces support load and helps the customer complete the process without extra email back-and-forth.

Localization and a Consistent Store Voice

If your site is in Russian, external instructions should also be in Russian, and technical field names should still be easy to understand. Labels like Payment Reference should remain only if that is the exact UI label or the term the customer will see in the external service. In other cases, a clearer local equivalent such as "payment number," "transaction number," or "payment comment" is usually better.

The gateway icon, name, and text should match the store's overall tone. An overly technical description lowers trust, while an overly promotional one creates false expectations. For B2B, precise business language works best. For a local store, use a short human-friendly instruction. For a payment link, make the manual confirmation aspect as clear as possible.

Why a Manual Payment Method May Fail and How to Find the Cause

Troubleshooting works best when you move from simple to complex. A manual gateway depends on WooCommerce, the theme, the checkout page, order statuses, email, the API, and sometimes an external system. If you change everything at once, the root cause gets lost. Below are the typical symptoms for WooCommerce Custom Payment Gateway Pro and similar manual payment flows.

The Payment Method Does Not Appear at Checkout

Symptom: the gateway is enabled in settings, but the customer does not see it among the payment methods.

Possible causes: the method is not actually enabled, debug mode is active and the user is not an administrator, checkout uses a block-based page with a conflict, cache is serving an old version of the page, or shipping/cart conditions from another plugin are hiding the method.

What to check: open WooCommerce - Settings - Payments, make sure the gateway is enabled, then test checkout in a private window. If debug mode is on, check the method as both an administrator and a regular user. Clear the checkout page cache and temporarily disable JavaScript optimization just for testing.

How to fix it: enable the gateway, turn off debug mode after testing, verify compatibility with block-based checkout, temporarily switch back to classic checkout to isolate the cause, or disable the conflicting payment-conditions plugin. If the theme is the issue, test with a default theme in staging.

Email to the Customer or Administrator Is Not Sent

Symptom: the order is created, but the customer or manager does not receive the expected email.

Possible causes: the chosen status does not trigger the needed WooCommerce email, the matching notification is disabled, the email goes to spam, SMTP is not working, or the email template has been overridden by the theme.

What to check: the order status after checkout, WooCommerce - Settings - Emails, the mail service log, and a WordPress test email. WPRuby's documentation specifically notes that for Pending Payment emails, you may need to change Order Status After The Checkout to Processing if that truly matches your process.

How to fix it: choose a status that triggers the required emails without breaking the operational workflow. If the status must remain manual, create a separate notification or manager work queue instead of moving the order into a paid status just to force an email.

Form Fields Are Displayed but Do Not Help Reconcile the Payment

Symptom: the customer fills something in, but the manager still cannot match the order to the payment.

Possible causes: the field name is too vague, the customer does not understand where to get the value, an optional field is skipped, the uploaded file contains nothing useful, or the instructions do not explain what payment note or reference to use.

What to check: the checkout instruction text, field labels, required status, example values, visibility of the data in the order and emails. Run the test like someone who does not know the store's internal process.

How to fix it: rename the field into a specific action: "Payment Order Number," "Transaction Number," "Accounting Contact," or "Payment Comment." Add a short example, but do not ask for unnecessary data. If proof is better uploaded after payment, do not make the file required at the first step.

The API Request Never Reaches the External System

Symptom: the order is created, but the CRM, spreadsheet, middleware, or payment service never receives the data.

Possible causes: the API URL is wrong, the external service expects a different request method, JSON is enabled in the wrong place, required headers are missing, the external service rejects the request, or the hosting environment blocks outgoing connections.

What to check: the URL, GET or POST method, data format, HTTP headers, WooCommerce API parameters, extra parameters, and the external system log. If the service requires a signature, token, or special callback, review its documentation.

How to fix it: start with a simple test endpoint that only accepts data. Then add parameters one by one. Do not store secrets in visible fields, and do not treat a customer redirect alone as success. Check the service response and the order status.

After Selecting the Manual Method, the Order Gets the Wrong Status

Symptom: the order looks paid before verification, or it gets stuck in a place where the team does not see it.

Possible causes: the wrong value is set for Order Status After The Checkout, store automation reacts to a different status, an external callback changes the order, or managers are filtering the order list based on old habits.

What to check: the status immediately after checkout, order notes, the behavior of external integrations, CRM rules, and email notifications. Test one order without the API and one with the API so you can see where the status changes.

How to fix it: choose a status that matches the real process. For manual review, do not use a fully paid status without a reason. If the external service should change the status after responding, configure return URL or callback handling strictly according to the provider's documentation.

When WooCommerce Custom Payment Gateway Pro Is the Right Choice

This plugin is worth using if your store needs more than just "another payment method" and instead needs a controlled manual flow: clear checkout instructions, extra fields, proof upload, multiple gateways, order status control, debug mode, and, if needed, data transfer to an external system. In that kind of task, WooCommerce Custom Payment Gateway Pro lets you assemble a workable payment flow without building a separate gateway from scratch.

Before a public launch, make sure you complete a full test: checkout, order, emails, status, API, external service, mobile view, and manager actions. If the scenario only works in the administrator's head, the customer will get confused quickly. But if the payment method explains the steps, collects only the necessary data, and does not present manual review as automatic capture, it can make payment much easier for B2B, local, invoice, payment link, and other non-standard orders.

Once the settings are verified and you understand the limits of the manual process, you can download WooCommerce Custom Payment Gateway Pro and test it on a site copy or in debug mode. That is a safer approach than enabling a new payment method directly on live checkout and fixing mistakes only after the first orders start coming in.