CardRaabta Manual Payments for WooCommerce

Accept manual bank transfers, mobile wallet payments and Raast payments in your WooCommerce store. CardRaabta displays your receiving details, collects payment proof and helps you review submissions before confirming payment. Customers transfer PKR to your existing receiving account and submit a screenshot or transaction reference. You check the actual funds in your account, then approve the payment or reject the proof with a helpful reason. No gateway merchant account, API keys or provider integration approval are needed to configure the plugin. You still need a suitable receiving account and must follow your provider's terms. CardRaabta is independent third-party software, not affiliated with or endorsed by WooCommerce or the payment providers. It does not verify funds automatically, connect to bank/wallet APIs, process cards or issue automatic refunds. How it works

1. Add your receiving account details and enable the methods you want to offer.
2. The customer selects a method and transfers the order amount using your instructions.
3. The customer submits proof at checkout, or later if you allow unpaid orders without checkout proof.
4. Review the submission in Transactions and verify the transfer in your actual receiving account.
5. Approve the payment, or reject the proof with a reason so the customer can correct it.

Bank, wallet and Raast methods Offer JazzCash, Easypaisa, SadaPay, NayaPay, Bank Transfer (IBFT), Raast, Zindigi, UPaisa, HBL Konnect, Cash Bank Deposit or a custom payment method. Configure a display name, account title, receiving number/IBAN/identifier, instructions and optional QR image for each method. Customers see the details matching their selection. These are receiving instructions, not direct provider integrations. Never enter account passwords or PINs. Checkout and customer payment proof

• Supports Classic Checkout, Checkout Blocks and WooCommerce HPOS.
• Responsive payment forms with receiving details and account-copy controls.
• Proof is required at checkout by default. Optionally allow unpaid orders with later proof submission.
• Configure screenshot, reference, date, note and confirmation fields. Use the same settings for checkout/order pages or separate rules.
• Screenshot and date are enabled and required by default; other fields start disabled.
• Every actual submission needs an enabled screenshot or reference. Dates must be valid and not in the future.
• JPG, PNG and WebP uploads; configurable 1–8 MB limit, default 5 MB, with server-side validation.
• Pending/Rejected proof forms open when the customer chooses to update proof. Paid orders cannot resubmit.

Registered customers use authenticated access. Guests use private order-key links and may need billing-email verification. File selection/preparation does not itself mean the server received the proof. Manual review and proof history Search by order/reference, filter by status and expand transaction details. Review individual payments or use confirmed bulk actions. Bulk rejection requires a customer-visible reason; approval accepts an optional note. Stale or ineligible records are skipped with a notice. Customers can replace Pending/Rejected proof under the same transaction ID. Earlier submissions and review decisions remain in manager-only history. Allow 1–10 replacements after the initial submission, default 3, between completed reviews. Completed rejection resets used attempts; changing the configured limit does not. Replacements are complete submissions, so omitted current fields are cleared while prior values stay in history. All transactions and Trash use pagination, with 20 rows by default and Screen Options for 1–100. Pending proof for an existing order must be reviewed before removal. Trash/Restore change visibility; they do not reverse payments, stock changes or refunds. Exports, notifications and Email Logs

• Separate manager-only CSV exports for current transactions and proof history, including recorded proof/review information.
• Screenshots appear as attachment IDs, without embedded files or public image URLs. Spreadsheet formula-prefix protection applies.
• Eleven customer/admin notification types covering proof received/updated, review decisions, missing proof and interrupted reviews.
• Configure admin recipients, notification switches and reminder delay. Customer messages use the order billing email.
• Edit email subjects, headings, messages, buttons and reviewer-note highlights; branding uses WooCommerce email settings.
• Desktop/mobile sample previews and logged test emails.
• Email Logs with masked recipients, transport status, attempts, filters and clearing controls.

Missing-proof reminders default to 15 minutes, configurable from 1 minute to 7 days, and recheck eligibility. Dispatch depends on Action Scheduler/WP-Cron and your mail transport. Mail-server acceptance does not confirm inbox delivery. Clearing logs does not cancel queued work or reset duplicate-send protection. Private evidence and data retention Payment screenshots use AES-256-GCM encryption and manager-only authenticated access. Back up the database, private evidence and crmp_evidence_key together; losing the key makes retained screenshots unreadable. Server-level protection is also required for private evidence storage: see Installation below. The plugin stores receiving details, proof, customer/reviewer notes, recorded field settings and email operational data. Queue recipients/message snapshots are scrubbed after 30 days; minimal deduplication metadata remains. Visible Email Logs have separate optional 30-day cleanup. Proof has no automatic expiry. Permanent transaction removal deletes proof, revisions and private notes while retaining minimal receipt/reference and decision metadata against duplicate approval. Uninstall retains data, settings, evidence and its encryption key; deactivation clears scheduled email work. There is no dedicated personal-data exporter/eraser. Managers should set an appropriate retention policy. No plugin analytics/tracking, remote executable code or payment-provider API calls are included. Customer confirmation is an assertion, not verification of received funds. Full documentation | Hosting setup guide

Requirements WordPress 6.5+, WooCommerce 8.3+, PHP 8.1+, OpenSSL and MySQL/MariaDB named-lock support. Use maintained software versions, HTTPS and a working site mail transport. Install and configure

1. Install and activate WooCommerce, then install and activate CardRaabta.
2. Under CardRaabta Payments > Payment Methods, enable methods, enter receiving details and save.
3. Enable the gateway under WooCommerce > Settings > Payments and use PKR currency.
4. Under CardRaabta Payments > Settings, configure proof fields, screenshot size, replacement limit, recipients, notifications and email templates.
5. Arrange private screenshot storage protection using the server checklist below before accepting screenshot submissions.
6. Place a staging order and test proof submission, manual approval/rejection, replacement and actual email delivery.

Server configuration: what is automatic? The evidence directory is the cardraabta-manual-payments-for-woocommerce subdirectory under your site's actual WordPress uploads base. With default uploads, its URL path is: /wp-content/uploads/cardraabta-manual-payments-for-woocommerce/

• Apache: the plugin creates .htaccess denial rules when the first screenshot is saved. Usually no manual rule is needed if mod_rewrite and the required directory overrides are enabled. Verify enforcement with your host.
• OpenLiteSpeed: the plugin creates the same rules. Rewrite handling and automatic .htaccess loading must be enabled for the virtual host; ask your host to confirm.
• Nginx, including an Nginx uploads frontend: .htaccess is ignored. A hosting administrator must add a deny rule to the configuration that actually serves uploads, validate it and reload Nginx.
• IIS: the plugin creates web.config authorization rules. URL Authorization must be installed and site/directory-level authorization configuration allowed; hosting assistance may be needed.

The plugin does not edit/reload server-wide configuration or automatically verify effective HTTP protection. Existing administrator guards are preserved. Finding a guard file or an empty index.php does not prove protection. Encryption still applies when a rule is missing, but direct access to private storage must be blocked. Protect the uploads evidence folder, not the plugin's public CSS/JS directory. Custom/multisite uploads paths, CDN/media hosts and proxy routing need matching protection. If screenshots are disabled and none have ever been stored, there are no evidence files to protect; disabling uploads later or uninstalling does not remove retained files. Verify private storage protection Ask your hosting provider to test on staging after the evidence folder exists:

1. Create a temporary readable crmp-access-test.txt inside it, containing a unique harmless marker, never customer information.
2. Request its real URL logged out, including with a query string, and check the directory URL. Expect 403/404; IIS may also return 401. The marker and directory contents must not be exposed. HTTP 500 is a configuration error, not a pass.
3. Check any CDN/proxy route, then confirm authorized managers can still view valid evidence and public plugin assets/receiving QR images work.
4. Delete the test file and keep effective denial rules in place.

Open CardRaabta Payments > Setup Guide or the complete server guide for Apache rules, the Nginx configuration example, IIS settings and a message to send your host. The menu opens GitHub when clicked; it does not send payment/customer data or configure your server. Upload limits, caching and backups PHP upload_max_filesize must cover your chosen screenshot limit; post_max_size and proxy body limits must allow the complete request, including roughly one-third base64 overhead for browser-prepared screenshots. Ask your host for appropriate uploads ownership/permissions. Exclude private commerce pages, order-key URLs, Store API checkout, wc-ajax and proof/CSV endpoints from full-page caches. Preserve checkout script dependencies, exclude required scripts from interaction delays and safelist dynamic crmp- / crmp_ CSS. See the full documentation for examples. Keep protected backups of the database, evidence files and encryption key together.

1.0.0

• Initial release with manual bank, wallet and Raast receiving methods.
• Classic Checkout, Checkout Blocks and HPOS support.
• Configurable payment proof, manual reviews, replacement history and CSV exports.
• Customer/admin email templates, reminders and Email Logs.
• Encrypted screenshot evidence and hosting setup guidance.