Passport - Application for Channel Entry
The channel entry application is the first step in channel management, just as a passport is required for an outbound trip. Of course, having a passport does not grant you access to any country or region. Different passports are required for different regions (passport, Hong Kong and Macau Permit, etc.). Similarly, different payment channels necessitate separate network access applications. It is critical to understand that a payment channel is not the same as a payment product in this context. There are corresponding payment products in different front-end scenarios, such as App payment and web payment, regardless of payment. So merchants do not need to use only one payment interface if they want to accept payment. Customers frequently assign the open platform's ID to the public platform, resulting in reported errors.
Creating payment orders with Visa
We still need to apply for a visa to leave the country even after we have a passport. We must provide some necessary information in this case, such as round-trip airline ticket information, destination hotel information, and so on. This is the same as creating a payment order, where we must provide the necessary order elements. The following points should be highlighted in this link.
The order number
If you create your own payment system, the order number is the first thing to consider. When saas payment gatewaydocking multiple payment products at the same time, we must first pay attention to the format of the order number; different payment product channels have different order format requirements, especially on the bank side. The second factor is the order number's uniqueness. In practice, the uniqueness of the order number is related to the business process as well as the technical implementation, such as whether the same order supports multiple payments. We propose that two dimensions be distinguished here: business orders and payment orders. A one-to-many mapping of business orders and payment orders solves the uniqueness problem.
The order's validity
Payment validity and refund validity are two aspects of order validity.
The merchant can customize the payment validity period, and it should be noted that different channels use different parameters, some of which are relative time and some of which are absolute time. The refund validity period is determined by the channel and varies by organization. As a result, when designing the business, we must consider the bare minimum. To ensure the correctness of the order information, orders that exceed the refund validity period of the channel and the business to allow refunds must be handled using special logic.
The distinction between mobile payment and payment / UnionPay mobile payment interface is analogous to visa type.
The merchant initiates mobile payments in the background, processing and preparing everything according to the channel's requirements, and then directly front-end to initiate the payment through the App called up by the control. This is similar to our visa-on-arrival system, in which one prepares the necessary materials and the other side's customs checks take place only after the plane lands.
Payment and UnionPay mobile payment, on the other hand, must first make a back-end request, and then the front-end initiates the payment action after the request is approved. This is very similar to a standard visa; if the information does not meet the requirements before obtaining the visa, the operation will be unable to proceed. This is where different payment channels' business logic differs, and the order sequence, content, and subsequent status updates of different channels must be considered in the payment gateway design.
Related Hot Topic
What payment processor does Microsoft employ?
Several payment methods, including credit card processing through PayPal and Stripe, are available through Microsoft Pay. Every invoice document can either have the Microsoft Pay link integrated automatically or manually by the user.