The specified version of the app (1.x.0) does not exist. This page is about the latest stable version, which is 1.0.1.
This project has the objective to allow it to integrate VTEX with the payment method Scalapay. To understand better the functionality between the VTEX interface and VTEX backend or VTEX IO and Scalapay, see the architecture define below.
The built of this project has the following parts:
- Frontend development, where was defined the payments steps to know as should use the base project "payment standard modal" to create external integration payments.
- Develop the integration with the connector to communicate the frontend with the backend VTEX.
Frontend Scalapay
The Scalapay integration allows making payments from VTEX checkout opening a window with Scalapay's external link. When the payment is done, the service is communicating with the VTEX backend to provide the response.
Depending on the type of response (SUCCESS or ERROR), the data will be present in the interface. If the pay response is successful, the user could see the payment information in the Order Place, but if the service response has an error, the user should choose another payment method.
To use the Scalapay method payment in the checkout choose the option as is shown in the image below
The Scalapay payment method only works correctly with currency EUR. If the user tries to make the payment with another option, it will show an error in the interface.
*The Scalapay payment method only works correctly with currency EUR. If the user tries to make the payment with another option, the modal will show an error. If the store not has currency EUR to pay for the products, contact the VTEX team through Slack.*
When the pay flow is correct, the flow looks as below images.
When you close the Scalapay window, the VTEX checkout modal shows a message to indicate the error. Also, a button appears to open the Scalapay window again and finish the payment.
But if the payment process failed in the Scalapay, the error will be shown in the modal and then the window will be reloaded to choose another payment method.
The development of the Scalapay interface is responsive allows adjustment in many devices.
The payment process has an inactivity time of 30 minutes. If completed or surpass the time, the payment will be canceled and you should start the payment process again.
Connector integration
To connect the front with the backend was created a folder with scripts in charge of consumption of REST service orderdetail (create order), capture (capture the order when the payment is successful), cancelation (it is used the payment failed or the modal is closed without finish the payment)
When the modal is open this gets the information of the payload (the payload is the VTEX backend response). If the field inboundRequestsUrl in the object has information, the request to the endpoint 'orderdetail' is started. The connector scripts contain the 'fetch' in charge of doing the request. This script uses the vtexPayment and inboundRequest. You could consider the node folder and files inside of this as the communication bridge
The inbound is the URL that VTEX assigns to you to make the backend consumption. This allows validating the payment to confirm or refuse it.
To see the source code, go to the following link:
This project uses the standard modal to create the frontend:
The project has like base to changes the status, this was used to change the payments steps according to the service response.
_10export enum States {_10 Loading = 'loading', // Starting the loading, here it shows the animation_10 Waiting = 'waiting', // The other steps pending_10 Success = 'success', // When the connector services response is successful_10 Error = 'error', // When the connector services respond with an error or request is failed._10 Active = 'active', // To show animation_10 NoPayment = 'nopayment', // The payment has not yet been done in the payment Scalapay window._10 Approved = 'approved', // The payment was successful. The Scalapay window will be closed._10}
The response code to default is 200 (Success) and 400 (Error). However, the backend can give other codes like 500, 403, 404, depends on the error type. In the source code are captured and controlled other error codes. Depending on the error code, the interface will indicate the internal problem to the user.
_10export enum Codes {_10 Success = 200,_10 Error = 400,_10}
Response services default, used and taken of Standard Modal Payment
_16export const responseService = {_16 success: { code: 200, message: 'Ok', status: 'success' },_16 notFound: { code: 404, message: 'Data Not Found', status: 'not_found' },_16 internalServerError: {_16 code: 500,_16 message: 'Internal Server Error',_16 status: 'internal_server_error',_16 },_16 forbidden: { code: 403, message: 'Invalid data', status: 'forbidden' },_16 unauthorized: {_16 code: 401,_16 message: 'Authentication is required',_16 status: 'unauthorized',_16 },_16 badRequest: { code: 400, message: 'Invalid request', status: 'bad_request' },_16} as const