Refunds failing with PY0009 error

General
1

Hi Team,

We raised an issue around refund failure observed during testing.

We received the following feedback from your team:

PY0009 is triggered only when the transaction you are trying to reference does not exist.

In Boku’s case, there are two live environments in production: BOKU 1 and BOKU 2. Based on our checks, the transaction you provided exists under BOKU 1.

Please make sure that you are performing the void/refund using the API keys for BOKU 1, as using the keys for a different environment (e.g., BOKU 2) will result in the transaction not being found and will trigger PY0009.

Hence, we wanted to check, how is it possible that we charge from one MID (which was successful) then refund with another MID? The only reference that we pass in refund (void request) is the “boku transaction id” hence can you please help us understand whether the analysis was correct and help us resolve this issue?

We will soon be starting our tests for PayFac model and this could become a blocker then hence the request.

During testing, the charge transaction was completed successfully. However, when we attempted to process a refund for the same transaction, the request failed and returned an error with code PY0009.

Please review the following logs and share your response or guidance on the PY0009 error encountered during the refund attempt?

Request:

2026-01-08 12:31:30,233 (mtQueueDefaultMessageListenerContainer-18) DEBUG [org.apache.http.wire] [trkId=ABF-oAWkJf5G] [trxId=1764703664267789374][msisdn=A_187d7b1509c3045d] http-outgoing-28482 >> "POST [redacted endpoint] HTTP/1.1[\r][\n]”

Response:

2026-01-08 12:31:30,503 (mtQueueDefaultMessageListenerContainer-18) DEBUG [org.apache.http.wire] [trkId=ABF-oAWkJf5G] [trxId=1764703664267789374][msisdn=A_187d7b1509c3045d] http-outgoing-28482 << “{“result”:“FAIL”,“sig”:{“timestamp”:1767875490,“nonce”:“e4e910534e2413940b73574cb0d93949b86d1c6b9a10e38cc3cf042567444129”,“signature”:“99A6F0D9723DA93E2726A673CBB765F30D4644DBB43AF43A2E472ADD315BB2C0”},“error”:{“code”:“PY0009”,“message”:“Payment does not exist.”}}[\r][\n]”

Request:

2026-01-08 12:29:09,153 (mtQueueDefaultMessageListenerContainer-8) DEBUG [org.apache.http.wire] [trkId=ABF-A43chb6M] [trxId=b4v0qmohfwc76qkudnvccpve][api=CHARGE_WITH_TOKEN][msisdn=A_187d7b1509c3045d] http-outgoing-28350 >> “POST /payby/v2/paymaya/link/b50494a6-bacc-44d1-ab48-24bc1d94fd3f/execute HTTP/1.1[\r][\n]”

2026-01-08 12:29:09,158 (mtQueueDefaultMessageListenerContainer-8) DEBUG [org.apache.http.wire] [trkId=ABF-A43chb6M] [trxId=b4v0qmohfwc76qkudnvccpve][api=CHARGE_WITH_TOKEN][msisdn=A_187d7b1509c3045d] http-outgoing-28350 >> "{“totalAmount”:{“currency”:“PHP”,“value”:“1.00”},“requestReferenceNumber”:“b4v0qmohfwc76qkudnvccpve”,“metadata”:{“pf”:{“smi”:“Boku2”,“smn”:“Boku2 PayMaya”,“mci”:“Seattle”,“mpc”:“608”,“mco”:“USA”,“mst”:“WA”}}}”

Response:

2026-01-08 12:29:10,463 (mtQueueDefaultMessageListenerContainer-8) DEBUG [org.apache.http.wire] [trkId=ABF-A43chb6M] [trxId=b4v0qmohfwc76qkudnvccpve][api=CHARGE_WITH_TOKEN][msisdn=A_187d7b1509c3045d] http-outgoing-28350 << “{“result”:“SUCCESS”,“data”:{“approvalCode”:“003247”,“receiptNumber”:“600812198547”,“receipt”:{“receiptNo”:“600812198547”,“approvalCode”:“003247”,“approval_code”:“003247”,“batchNo”:“20260108”,“transactionId”:“dc008b54-e61”},“id”:“46c09769-50aa-4860-a46c-73422846b1be”,“status”:“PAYMENT_SUCCESS”,“requestReferenceNumber”:“b4v0qmohfwc76qkudnvccpve”,“canVoid”:true,“metadata”:{“pf”:{“smn”:“Boku2 PayMaya”,“mpc”:“608”,“mci”:“Seattle”,“mco”:“USA”,“mst”:“WA”,“smi”:“Boku2”}},“isPaid”:true,“createdAt”:“2026-01-08T12:29:09.421Z”,“updatedAt”:“2026-01-08T12:29:10.239Z”,“canCapture”:false,“currency”:“PHP”,“fundSource”:{“type”:“card”,“details”:{“issuer”:“SmartPay”,“scheme”:“master-card”,“last4”:“4986”,“first6”:“542482”,“profileId”:”************“,“masked”:“542482******4986”},“description”:”**** **** **** 4986",“id”:“jh5BLwrthEQf2qOoUaXMleKQ7hwghYNlcR97fr2kvK7vi4PeVIypGsSNAOwB9u9qUuUqscc6xtt7qQlCcakuzLdeIVs6T9eOwwd082mMx4PwAjXNvletN4vS3Dy04If4rZBWYxZWeVJeTRixqPQyu6BCydUZpgNxRr33Ac”},“canRefund”:true,“amount”:“1”},“sig”:{“timestamp”:1767875350,“nonce”:“bc0b8469fe2cc98ddf00c6dadbae3f78fa1be2e718fc8076eb4a0bd04ac265f4”,“signature”:“148BE08AEC9C52776A7DCD1B705E124BAE7FD5A22E25C6140F495E1C4813608F”}}[\r][\n]”

cc: @renzoatos fyi

2

The PY0009 error occurs when the transaction you are trying to reference does not exist. In your case, it seems you may be referring to using the API keys for a different environment (e.g., BOKU 2) for the refund, which results in the transaction not being found. Ensure that you are using the API keys for BOKU 1 for both the charge and refund transactions.

For Sandbox concerns and other technical implementation inquiries, please get in touch with us via:

  • Sandbox Health Page: Check real-time service status updates.
  • Maya Developer Hub Service Desk: File
    a ticket in Sandbox.

To Know More:

We value your input and would love to hear your insights. Please submit you feedback here.

3

Hi Team,

We were testing on production environment and used the same API keys for both charge and refund. Hence we are unsure how can there is a discrepancy in the API keys.

4

Hi @jwadkar,

Thanks for sharing the detailed logs and for the clarification.

To address your questions directly: A transaction can only be voided or refunded using the same API key and environment where it was originally created.

In your case:

  • The charge transaction was successfully processed under BOKU 1
  • Any subsequent void or refund request must also be performed using the same BOKU 1 API key
  • If a refund or void is attempted using an API key tied to a different MID or environment (for example, BOKU 2), the transaction will not be found, which correctly results in PY0009 – Payment does not exist

Even if the request reference or Boku reference ID is valid, cross-MID or cross-environment operations are not supported.

Validation via Maya Business Manager

You can also validate this directly in Maya Business Manager, where you can:

  • Confirm which MID was used for the original charge
  • Verify whether the void or refund request was executed under the same MID

Please note that this developer forum is not intended for investigating production issues or troubleshooting live transactions.

Since this issue involves production transactions and environment-specific validation, we recommend reaching out to the appropriate support channel so the team can securely review your setup and production transactions: business.support@maya.ph

We hope this clarifies the behavior you’re seeing. Let us know if you have any questions related to sandbox testing or general integration flows.

1 Like
5

Thanks @genson.cerezo for your response!

@renzoatos could you please confirm whether the MIDs are shared as below?

Could you please confirm whether this transaction was processed under the Boku (EFS100812635) product and not via Boku 2 (EFS201024325), vice versa?

6

Hello @jwadkar, if you have access to Maya Business Manager, I think you can verify this directly by checking the Transactions List. From there, you’ll be able to confirm which MID was used for the charge and which MID was used during void attempt (e.g., BOKU 1 vs BOKU 2)

This may help validate whether the transaction was processed under BOKU 1 or BOKU 2, and rule out any MID or environment mismatch.

2 Likes