Online Payments Troubleshooting

This guide covers the most common issues encountered during myPOS online payment integration — from error codes and callback failures to WooCommerce plugin problems and advanced feature activation.

---

Error Code Reference

---

URL_Notify (Callback) Requirements

Your URL_Notify endpoint is called by myPOS after every payment attempt. It must return:

What happens when the callback fails:

A failed URL_Notify triggers an automatic IPCPurchaseRollback. The transaction is reversed and the customer's card is not charged — even if the checkout page showed success.

Common causes of callback failures:

Debugging steps:

1. Check your server access logs for the incoming POST request from myPOS.
2. Inspect the raw response body your server returns — not just the HTTP status code.
3. If you suspect Cloudflare blocking, temporarily pause Cloudflare protection and retry to confirm.
4. Whitelist myPOS IP address: 34.65.222.69

---

Amount & Parameter Formatting

Incorrect formatting of monetary values is a common cause of payment failures:

• All monetary values (unit price, shipping, discounts, fees) must be rounded to exactly 2 decimal places.
• The total amount must equal quantity × price, both rounded to 2 decimal places.
• The Amount parameter must be a double (e.g. 23.45) — not a string, not a formatted value with extra characters.
• The quantity parameter must be an integer (e.g. 1, 2) — not a float.

---

Signature Errors

If you receive INVALID_SIGNATURE or E_SIGNATURE_FAILED:

---

WooCommerce Plugin Issues

Configuration checklist

Blank checkout page

If the checkout page displays a blank screen, a conflicting plugin is the most likely cause. Deactivate all third-party plugins except the myPOS plugin and WooCommerce, then test. Re-enable plugins one by one to identify the conflict. Known problematic plugins include TranslatePress and some caching plugins.

Apple Pay & Google Pay

Apple Pay and Google Pay are included by default in the WooCommerce plugin — no additional configuration is required. These only work in the production environment (isSandbox=false); they cannot be tested in the sandbox.

---

Transaction Rollbacks & Missing Payments

If payments appear successful in the checkout UI but do not appear in your myPOS account:

1. Check the URL_Notify endpoint first — a failed callback causes automatic reversal.
2. Check the correct store — in the myPOS admin portal, confirm you are viewing the statement for the right store, not a different one.
3. Check for PHP errors — any warning or deprecation notice in the response body will cause the callback to fail.

Customer claims funds were withdrawn but order is cancelled

When a transaction is unsuccessful (due to URL_Notify failure), the payment is automatically reversed. Funds are returned to the customer's account. The reversal may take 1–3 business days to appear on the customer's statement depending on their bank.

---

3DS & Card Declines

These are bank-side decisions — myPOS cannot override card decline reasons.

---

Pre-Authorization

IPCPreAuthorization is not enabled by default. The feature must be explicitly activated on the merchant's account by the myPOS team.

To request activation: contact myPOS support with your account details.

Key rules once activated:

• Pre-authorizations made via the PHP SDK or Checkout API must be completed or cancelled through the same API. Do not mix API pre-auths with terminal pre-auths.
• The maximum period between authorization and capture depends on your business type (typically up to 30 days).
• If a COMPLETE_PREAUTH fails, implement an automatic retry mechanism.
• If a pre-authorization cannot be completed, use the CANCEL_PREAUTH method to release the held funds.

---

Recurring Payments

Recurring payments are not enabled by default — contact myPOS support to activate them for your account.

Implementation steps once activated:

1. Use IPCPurchase with CardTokenRequest=2 to store the card and obtain a token.
2. Use IPCIAPurchase for subsequent charges using the stored token.
3. Use small test amounts during card tokenization to avoid unnecessary bank declines.

---

Split Payments & IPCSendMoney

myPOS does not support automatic split of a single payment into multiple accounts.

Workaround: Use separate myPOS accounts. After funds settle, use IPCSendMoney to transfer the partner's share. Note:

• IPCSendMoney must be activated by myPOS support — it is not available by default.
• The transfer process can be automated via the myPOS API.

---

IPCReversal Common Mistakes

IPCReversal requires these parameters in addition to the order ID:

• sid — Store ID
• keyindex — Key Index

Both are commonly omitted, causing the reversal to fail with a generic error.

If the reversal fails:

• Error 113 ("Operation Already Processed") → use IPCRefund instead.
• "Insufficient Funds" error → use IPCRefund instead.

---

EEA Restriction

myPOS payment processing is restricted to EEA (European Economic Area) countries. Transactions initiated from outside the EEA may be blocked by automated security systems.

If you are a developer testing from outside the EEA and payments are being declined without a clear error, try using a VPN set to a European country. This is a testing workaround only — production traffic should originate from within the EEA.