Examples of node items:
Clarification: Images must support HTTPS, otherwise they will not be displayed. To place subscriptions inside the checkout, an object must be added to the items array with the type "subscription" and as reference the UID of the subscription to which the subscriber will be associated.
Examples of node sources:
Examples of node installments:
There are 3 ways to Limit Plans:
- Hide certain plans from the entire set of existing plans:
- Limit the Plans selected in the Array:
- Show special plans based on Advanced Rules:
For available payment sources and installment plans, see Payment methods and installments Payment Methods and Installments.
The created checkout can only be used for 60 (or the time defined in the Timeout variable) minutes, after that it will expire. If the customer tries to pay after this period he will be redirected to the url declared in return_url with status 401 (Expired).
This attribute is used to avoid duplicate payments. It must be unique for each payment transaction to be identified, as Mobbex will NOT allow 2 transactions in "Paid" status with the same reference.
The checkout module is enabled to use the 2-step transaction or "Authorization and Capture". This special type of operation requires previous authorization of the merchant to be able to use it. Documentation on the transaction flow and implementation details can be found at the following link.
By defining the return_url parameter the service will redirect to the URL provided by HTTP Get once the transaction is completed. To this url will be added the status of the transaction through the status parameter, the type of transaction generated by the user through the type parameter (cash/card) and the transaction identifier through the transactionId parameter.
If the user cancels the transaction status will be 0 and type will be none. This as noted indicates that the user did not finish the operation and decided to return to the site.
It is very important to review the documentation on status and types of documentation as the handling of these will be used during the Mobbex trade approval. This documentation can be found in the following link: Statuses and Transaction Types.
To avoid that a Checkout remains pending of payment after a certain time, they have a default time limit of 60 minutes that can be customized via the "timeout" parameter when creating the checkout by sending the maximum number of minutes you want the checkout to remain active. The minimum number of minutes is 1 minute.
When a Checkout Expires or Expires the service automatically sends a notification via Webhook. This Webhook has a special form described below. It should be noted that this Webhook is not similar to the operative Webhooks.
Once this Webhook is received, it is understood that the Checkout can no longer be paid and it is recommended to return the Stock or take the necessary actions from your Backend.
The "data" field will be sent when there have been unsuccessful payment attempts, this field serves as a control of the operation.
This special webhook will NOT be sent when there is an operation in the following states:
This parameter should be used to limit the Webhooks received, for example when we only want to be notified when a transaction reaches a final status but not when there are unsuccessful payment attempts.
Webhook Type Options:
- all: This is the default option and the service will send any transaction attempt made by the customer during Checkout payment.
- final: Webhooks will only be sent when the customer reaches a final status, such as an Approved payment. All other statuses will not be sent although the checkout status will be sent in the Expiration Webhook discussed above. States that will be notified: 200, 3, 300, 301, 2.
- intermediateAndFinal: Intermediate statuses will be sent to the previous option, e.g. a transaction under review for fraud. Additional states to the "final" type that will be sent: 100, 210.
- none: In this option no checkout will be sent even if the url of the checkout is defined. Only use this option in special cases. If you use this option you must get the status of the checkout via API using the defined "reference".
If the checkout expires and the operation changes status, for example from "On Hold (2)" to "Rejected (400)" the notification will be sent in "all", "final" and "intermediateAndFinal" types, only it will not be sent in "none" type.