Issue Summary
It appears that the system allows multiple app-to-user transactions to be submitted using the same Payment ID. Then, when invoking getPayment before completePayment, the API response returns null for the transaction even though the transaction(s) is/are already visible in the blockexplorer. Finally, when invoking completePayment, it appears that only one transaction can be marked "transaction_verified": true and "developer_completed": true , the other(s) result in Bad Request. This potentially leads to rogue submitted payments.
Expected Behavior
Submitting a transaction with a Payment ID for which a transaction is being processed or has been processed should be rejected.
getPayment should return the transaction details once it is visible in the explorer, even if completePayment has not yet been called.
Actual Behavior
Duplicate submissions with the same Payment ID are allowed.
getPayment returns null until completePayment is executed, even though the transaction already exists on the network.
Steps to Reproduce
Submit an app-to-user transaction with a given Payment ID.
Submit the same transaction again using the same Payment ID.
✅ Transaction is accepted multiple times instead of being rejected as a duplicate.
Call getPayment for that Payment ID before calling completePayment.
❌ The response for transaction is null, despite the transaction being visible in the explorer.
Example Transactions
https://blockexplorer.minepi.com/testnet/transactions/4c450a6d5a323f9e1e258560a1617f2d57c8eb7bff7eb69a5c22c618c8d7bd73
https://blockexplorer.minepi.com/testnet/transactions/ef45f080cf038db21d814d627c27f66bbd5028c104f52cefb438818a2de2a257
Example Response
{
"identifier": "HP3fApBUiUEQDU0cwbZg4xLcyfhk",
"user_uid": "7decc80c-892b-4ae8-ab23-6cd4c9f52deb",
"amount": 0.06,
"memo": "App-to-User Payment - 1755608555",
"metadata": {
"someIdHere": "12345-abcde-45678-fghij"
},
"from_address": "GAKHSOB5Y7CM2WOR2HR6WAAZX2FFUIFTUJY6QEI3QEZ6BFXDFMBT7ZHB",
"to_address": "GC7AWC6R6VHINPGECG54NJZ4HMSVHIOVLTPWXASWK3SXZKTTHEEHUWRK",
"direction": "app_to_user",
"status": {
"developer_approved": true,
"transaction_verified": false,
"developer_completed": false,
"cancelled": false,
"user_cancelled": false
},
"transaction": null,
"created_at": "2025-08-19T13:02:45.712Z",
"network": "Pi Testnet"
}
Issue Summary
It appears that the system allows multiple app-to-user transactions to be submitted using the same Payment ID. Then, when invoking getPayment before completePayment, the API response returns null for the transaction even though the transaction(s) is/are already visible in the blockexplorer. Finally, when invoking completePayment, it appears that only one transaction can be marked "transaction_verified": true and "developer_completed": true , the other(s) result in Bad Request. This potentially leads to rogue submitted payments.
Expected Behavior
Submitting a transaction with a Payment ID for which a transaction is being processed or has been processed should be rejected.
getPayment should return the transaction details once it is visible in the explorer, even if completePayment has not yet been called.
Actual Behavior
Duplicate submissions with the same Payment ID are allowed.
getPayment returns null until completePayment is executed, even though the transaction already exists on the network.
Steps to Reproduce
Submit an app-to-user transaction with a given Payment ID.
Submit the same transaction again using the same Payment ID.
✅ Transaction is accepted multiple times instead of being rejected as a duplicate.
Call getPayment for that Payment ID before calling completePayment.
❌ The response for transaction is null, despite the transaction being visible in the explorer.
Example Transactions
https://blockexplorer.minepi.com/testnet/transactions/4c450a6d5a323f9e1e258560a1617f2d57c8eb7bff7eb69a5c22c618c8d7bd73
https://blockexplorer.minepi.com/testnet/transactions/ef45f080cf038db21d814d627c27f66bbd5028c104f52cefb438818a2de2a257
Example Response