Testing
This section explains how the "Paynet Direct" extension can be tested in order to verify that it works properly. Tests can be carried out using the paynet demo key certificate. It is located in the "settings" directory of the extension (it is "called paynet-demo-keycert.pem.php"). The default configuration makes use of this file. The MerchantID can be set to any number.
Credit card testing
- Visit the eZ Publish site like a regular customer would do.
- Put some items in the basket and execute the checkout process.
- When promted to enter credit card information, use the numbers from the table below.
| Credit card number | Description | Expiry date |
|---|---|---|
| Random number. |
Invalid card number. |
Any. |
| 4444333322221111 |
Valid VISA test. |
Any. |
| 5555555555554444 |
Valid Mastercard test. |
Any. |
The VISA and Mastercard numbers should validate and thus allow the contents of the basket to be purchase. Using a random number should not process and will produce an error message. It is a good idea to test the system with several users and multiple scenarios; more testing usually equals a better / safer environment.
The transaction log
The "Paynet Direct" extension provides a view that can be used to generate an overview of all transactions. This view can only be accessed by users with sufficient permissions (for example the "Administrator User"). The following screenshot shows an example of the output that will be generated when the transaction log is requested.
Transaction log
The transaction log is probably the best view to test or debug the paynet orders. The latest order approvals from the Paynet server appear on the top of the list.
The list has the following columns:
| Name | Description |
|---|---|
| ID |
The ID of the transaction. Click on the link to see the transaction details. Most of the information is already available in the transaction log, but it also includes the raw data sent from the paynet server. |
| Relates to |
The relation to another entry in the log. For example a refund from a previous order (the customer paid too much). The refund will relate to the first transaction that bought the product. |
| Time |
The time the order was processed. |
| Type |
The type of the transaction. This will be either "sale" or "refund". More information can be revealed when this field is combined with the "status" field (see below). |
| Status |
Possible values are "ok", "failed" and "rolled back". When combined with the "type" field, the following information is revealed:
|
| Order ID |
The ID number of the order (as a link). The link brings up a view that shows the products/services that the customer bought. |
| User ID |
The ID number of the user that represents the customer (as a link). The link brings up a view that shows a complete overview of all orders that the user has placed. Please note that this list might be very long for the Anonymous user. |
| CC Type |
The type of the credit card that was used (as a link). The link brings up the transaction view which can also be accessed from the Paynet oderview (both views will be discussed later). |
| Amount |
The amount of transferred money. |
The transaction log shows a detailed log of every transaction that has been made. It is useful when something goes wrong and needs to be checked. When everything works, it is probably easier to use the Paynet direct orders.
The order view
This view shows a list of payed orders. New orders will appear on the top the of the list. Note that only the orders that have been payed end up in this list. The following screenshot shows an example of the output that will be generated when this view is requested.
Paynetdirect orders
The columns of this list are:
| Name | Description |
|---|---|
| ID |
The ID number of the order (as a link). The link brings up more information about the order itself (works in the same way as the ID link in the transaction log). |
| Time |
The time when the order was placed. |
| Customer |
The name of the customer who placed the order. Note that this is not the user name. |
| Total (ex VAT) |
The total price not including VAT. |
| Total (inc VAT) |
The total price including the VAT. |
| Debit |
The amount of money that was transferred from the customer to the retailer - both should be "happy" when the debit equals the Total (inc VAT) value. |
| Creditcard |
The type of creditcard that was used (as a link). The link brings up the transaction view. |
| Status |
The status of the order. The shop administrators can (should) change these to keep track of the orders. |
To get a more detailed view on the money transfers click on the creditcard link.
The transaction view
The transaction view shows the transactions done for a specific order. The following screenshot shows an example of the output that will be generated when the transaction view is requested.
The transaction view
Usually one transaction belongs to an order. The transaction view shows in that case only one "sale" action. Multiple transactions belonging to one order is also possible. The retailer can transfer money back and forth to and from the customer by clicking, respectively, the "Refund customer" and "Charge (extra) from customer" buttons. The retailer chooses the amount to refund or charge and presses "OK". A new transaction appears in the transaction view. Notice the change in the debit amount.
Refunding is useful when a customer paid too much. Some examples are: the customer gets a discount or the customer chose the wrong country and pays therefore too much VAT.
Charging extra can be useful when the retailer refunded too much or extra costs can only be determined later (e.g. shipping costs).
Most of the fields are obvious except for the Tref and Authnr fields. These values come from Paynet and may be useful when the expertise from Paynet is required.
Permissions
Different customers should not be able to see eachother's orders. A customer should only have access to the "buy" function of the "shop" module. If it is possible to tamper with the URL to see other people's orders, then something is wrong. It is highly recommended to make sure that this is not the case; the following procedure can be used.
- Log in as user "A" and put some items in the shopping basket.
- Do a complete checkout and pay using one of the test credit card numbers.
- When the order is shown, copy the URL from the address bar of the browser.
- Log out user "A".
- Log in as user "B".
- Attempt to access the URL that was copied in step 3.
The system should respond with an "Access denied" message. However, if user "B" is allowed to see the order of user "A", then the permission settings are wrong.
Testing and monitoring failed transactions
The "FakeError" setting in the "paynetdirect.ini" configuration file makes it possible to generate fake error messages. When set to "enabled", the Paynet server will return a random error whenever one of the test credit cards is accepted. In other words, this makes it possible to simulate a scenario where the actual transaction fails. Failed transactions should be clearly visible in the transaction log (see above). It is recommended to verify that failed transactions are properly logged before going public with the site. The "FakeError" setting should only be used for testing purposes and must be set to "disabled" when the site is released.
Raymond Bosman (31/03/2005 3:10 pm)
Svitlana Shatokhina (25/10/2006 12:14 pm)
Comments