Test suite is broken

[erkurita]

Hello,

From the PR #2 I found out most of the tests uses a hard-coded merchant ID to perform the testing. I've modified the test suite to use an specific merchant ID via a parameter in the config.json, but even then half of the tests still fail due to unrelated errors:

{
    "errorId": "3cf0dc2f-888b-4acd-ae48-288e09d90166",
    "errors": [
        {
            "code": "102060",
            "message": "ACTION DO_PAYOUT IS NOT ALLOWED FOR MERCHANT XXXX",
            "propertyName": null,
            "requestId": "4296"
        }
    ]
}

{
    "errorId": "43b7b4c9-e106-4f0b-82a0-3f90f46fd5b8",
    "errors": [
        {
            "code": "21000020",
            "message": "VALUE *************** OF FIELD CREDITCARDNUMBER DID NOT PASS THE LUHNCHECK",
            "propertyName": null,
            "requestId": "4294"
        }
    ],
    "paymentResult": null
}

{
    "errorId": "1a7966ad-05e9-4262-9724-5feba94ffaf9",
    "errors": [
        {
            "code": "20000000",
            "message": "PARAMETER_NOT_FOUND_IN_REQUEST",
            "propertyName": "token.mandate.paymentProductSpecificData",
            "requestId": null
        }
    ]
}

to show a few.

Errors aside, the test suite should not be doing requests to the server unless it has to, via integration tests. There are appears to be little, if any unit tests with which ascertain the proper functionality of the codebase.

[aadmathijssen]

Hi @erkurita,

Thanks for reporting this issue.

If I'm correct, the issues with the current test suite can be categorized as follows:

• The integration tests are written against an internal testing environment using multiple merchant id's for different scenario's. Normal sandbox users cannot these tests as they have been assigned a different merchant id. In order to fix this, users should be able to provide their own merchant id (as you have indicated). This will not fix all tests, because the configuration of some of the merchants used is different from the merchant configuration of a default sandbox account.
• Some tests fail due to issues regardless of the issues with hard-coded merchant id's or differences in merchant configurations. As I understood, these issues are fixed in the upcoming release.
• Integration tests should be replaced by unit tests, if possible. You're right, this should be improved upon.

I have created an internal issue to resolve the above issues.

Aad

[emranch31]

have the same issue
when doing payout, I got this issue
ACTION DO_PAYOUT IS NOT ALLOWED FOR MERCHANT XXXX

[rob-spoor]

That means that payouts are not enabled for this merchant at this moment. Please contact Ingenico about this.

[emranch31]

alright.. can you please tell me which are the exact features inginico author sandbox user ?
because I cannot able to perform capture payment. but to alternate to capture payment, payments are working as approved payments

[emranch31]

how can I use a token for another payment?

[rikvanthof]

The sandbox accounts that we make available indeed don't offer all functionality. Behind the Sandbox we currently only expose the Global Collect payment platform and this platform doesn't yet support multiple partial captures, while the Ogone payment platform does support this. The API is used for both platforms, but the sandbox only offers the functionalities as provided by the Global Collect payment platform.
Regardless of the platform the transaction status determines what actions you can perform. A status of PENDING_APPROVAL expects an approval call to start the capture process, while a PENDING_CAPTURE expects a capture call to start the capture process. The first one simply changes the state of the transaction as only one capture is possible, while the second one actually creates new capture objects that have their own state.

Regarding your second question regarding the use of tokens, simply add the token to the create payment instead of the card details (in case of a card transaction). For the create payment in case of card you should send in the token in the token field in the CardPaymentMethodSpecificInput object. Please see https://epayments-api.developer-ingenico.com/s2sapi/v1/en_US/php/payments/create.html#payments-create-request for more information.

[emranch31]

I am very grateful for your cooperation. in my case, whenever I run a test call to create a payment, its status
is PENDING_APPROVAL and after approval, I got this status CAPTURE_REQUESTED. I think I don't need to run the capture API's because, after some time, the payment status gets itself changes to Paid
please let me know if am correct

[rikvanthof]

This is indeed correct. The PENDING_APPROVAL state basically means that we are awaiting your approval to capture the funds. With the /approve call you put the transaction in the queue to be captured. On the sandbox we have a script running that marks transactions as PAID to simulate the process. On production the transaction will stay at CAPTURE_REQUESTED for several days, before we see the funds on our account and report the transaction as paid.