Certification SDK.
Congratulations, you are getting closer to receive card payments!
Certification.
Once the PinPad integration part is completed in your project, it is necessary to perform test cases with different transactions to certify that the messaging has been implemented correctly, as well as the information on the tickets is in accordance with the regulations we currently have.
Once these test cases are done, you can proceed to register with productive credentials and deploy a productive pilot to verify that everything is working correctly.
Note.
It is required that the certification have some cards to carry out the tests. These may be Debit or Credit cards with PIN and digital signature. Expired or canceled cards can be used.
Remembering that the integration is carried out in a test environment and no charge is made to the card.
Important.
Consider that in case of using a card with a PIN, it must be entered correctly since the terminal validates that it is the correct one and in case of entering it incorrectly it could cause the card to be blocked.
Validation CheckList.
| Indicator. | Detail. | Restrictions. |
|---|---|---|
| Folio Field Management | Was the Folio field implemented in the integration? | *Mandatory. |
| Management of logs in the application. | Were service logs implemented on the point of sale side? | *Mandatory. |
Important.
The use of response times implemented in your mobile application prevents the process from being carried out successfully, since if the person takes more than the established time to carry out the transaction, it will cause the timeout not to respond and errors or unwanted situations to occur, such as that the transaction does not conclude at the point of sale.
Transactional operations.
| Test type | Card type | Expected result | Restrictions |
|---|---|---|---|
| Regular sale. | Credit-Chip. | Approved transaction. | *Mandatory. |
| Regular sale. | Debit-Chip. | Approved transaction. | *Mandatory. |
| Regular sale. | Card without PIN. | Approved transaction. | Only if the business has a card without a PIN (AMEX). |
| Regular sale. | Band card. | Approved transaction. | Only if the business has Band. |
| Sale MSI (3 , 6, 9, 12 y 18) | Credit. | Approved transaction. | Optional only if the merchant does not implement the MSI. |
| Sale MSI. | Debit. | Cause error "Promotion not valid for this type of card". | Optional only if the merchant does not implement the MSI. |
| Cancel sale by means of the terminal button. | N/A. | "Canceled by user." | *Mandatory. |
| Error handling. | Indistinct. | Provoke fraud rule code 34 transaction rejected (Test in conjunction with Netpay). | *Mandatory. |
| Mobile app timeout test for response times. This test is intended to detect that there are no defined response times in the mobile application to be certified, since if a scenario arises in which the client takes time to carry out the transaction, the response information can be successfully received in the application mobile regardless of the time taken by the client. | NA. | Sale. During the printing of the business receipt and the printing of the customer's receipt, in the same way, a period of time between 3 to 5 minutes should be expected. | *Mandatory. |
Warning.
Tests with * are mandatory for certification.
Cancellation Operation.
| Test type | Card type | Expected result | Restrictions |
|---|---|---|---|
| Cancellation | Indistinct | Cancellation of a sale made on the same day. | It is recommended to implement cancellations. |
Reprint Operation.
| Test type | Card type | Expected result | Restrictions |
|---|---|---|---|
| Re-print approved ticket. | N/A | The terminal will print the ticket correctly. | Optional only if the merchant does not implement reprinting. |
| Re-print ticket of a canceled sale. | N/A | The terminal will print the ticket correctly. | Optional only if the merchant does not implement reprinting. |
Steps after successful certification.
- An email will be received with the results, the same obtained with the certified operations in a controlled testing environment.
- The commercial team will be coordinating the generation of productive and pilot accesses.
- Upload the certified application to the PaxStore. See next step
Process for uploading the client's app to the PAXStore.
When the integration being carried out is of the SDK type, it is important to consider afterwards that the application must be certified by the NetPay team. It is required to upload the APK of the merchant to the PAXStore store, this in order get fast access and download the application on their Smart devices.
To do this follow the next steps:
- Register access to the Whatspos portal.
- Sign the APK of the merchant (In coordination with NetPay).
- The customer must upload the APK certified by NetPay in the store.
- The production team performs a scan and approval of the app to upload to the store (available for production).
Note.
For more information on how to upload your app to the PAXStore, request access to the following drive from NetPay's Integration team. (https://drive.google.com/file/d/1BsD39Kq2xn_jZ3brOTE--J71i4UEgaqY/view?usp=sharing)
Warning: PROGUARD (release).
After compiling the app in release mode using proguard or some security method, the following line of code must be entered in your application:
-keep class mx.com.netpay.sdk.models.* { ; }.
Note.
Verify that the Merchant Network does not have a block on the following ports and EndPoints:
Ports: 3334, 3317 and 443
Endpoint: suite.netpay.com.mxExample of timeout failure when blocking ports:
OkHttp : <-- HTTP FAILED: java.net.SocketTimeoutException: failed to connect to suite.netpay.com.mx/200.53.144.37 (port 443) after 25000ms
System.err: java.net.SocketTimeoutException: failed to connect to suite.netpay.com.mx/200.53.144.37 (port 443) after 25000ms.
Updated almost 2 years ago