Universal payment method, device and system based on Flutter cross-platform framework

Abstract

The invention discloses a universal payment method, device, system and equipment based on a Flutter cross-platform framework, and the method comprises the steps: obtaining the configuration data of payment channels from a remote configuration server when detecting that the payment system is started, and displaying the started payment channels in a Flutter interface to form a payment channel list; receiving a target payment channel selected by a user from the payment channel list and initiating a payment request, the payment request including order information and a payment channel identifier; sending the payment request to a matched native adaptation layer through a pre-established platform channel, so that the native adaptation layer calls a corresponding payment SDK to execute payment operation according to the payment channel identifier; and receiving a payment result returned by the native adaptation layer through the platform channel, and updating a Flutter interface for display according to the payment result. The development and maintenance workload can be reduced, the cost is reduced, and cross-platform unified payment is realized.

Description

Technical Field

[0001] The present invention relates to the field of online payment technologies, and in particular to a universal payment method, device, and system based on the Flutter cross-platform framework. Background Art

[0002] With the increasing popularity of smartphones and mobile payments, integrating multiple payment methods (such as Alipay and WeChat Pay) into apps has become a key requirement for improving user experience. However, payment interfaces vary between mobile platforms (Android and iOS). Traditionally, developers have needed to write payment integration code for each mobile platform, resulting in high development costs, complex maintenance, and potentially inconsistent user experiences due to platform differences. To reduce the workload of cross-platform development, the industry has introduced cross-platform development frameworks such as React Native and Flutter.

[0003] When developing payment functions, multiple payment methods require handling different SDK calls, page redirects, and result callbacks. However, traditional native development methods require implementing payment processes separately for Android and iOS, which is a labor-intensive process. While the H5 web payment solution can simplify development, it suffers from deficiencies in security and user experience, such as low security levels and easy tampering of payment information. Existing technical solutions include native multi-channel SDK integration and aggregated payment SDK / H5 hybrid solutions, but these solutions suffer from numerous drawbacks, such as the need for repeated development for different platforms, complex maintenance, the need to modify multiple terminal codes when payment channels change, and inconsistent user experiences due to differences in native and H5 interface styles. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to propose a universal payment method, device, system and equipment based on the Flutter cross-platform framework, aiming to solve the problems of high development and maintenance costs, poor user experience and insufficient security in existing payment integration solutions.

[0005] To achieve the above objectives, the present invention provides a universal payment method based on the Flutter cross-platform framework. The method is implemented based on the payment system built by the Flutter framework, and the method includes:

[0006] When detecting that the payment system is started, obtaining configuration data of the payment channel from the remote configuration server, and displaying the enabled payment channels in the Flutter interface to form a payment channel list;

[0007] receiving a user selecting a target payment channel from the payment channel list and initiating a payment request, wherein the payment request includes order information and a payment channel identifier;

[0008] Sending the payment request to the matching native adaptation layer through a pre-established platform channel, so that the native adaptation layer calls the corresponding payment SDK according to the payment channel identifier to perform the payment operation;

[0009] Receive the payment result returned by the native adaptation layer through the platform channel, and update the Flutter interface for display according to the payment result.

[0010] Preferably, sending the payment request to a matching native adaptation layer through a pre-established platform channel, so that the native adaptation layer calls a corresponding payment SDK according to the payment channel identifier to perform the payment operation, includes:

[0011] Determining whether to jump to a third-party payment application according to the payment channel identifier by the native adaptation layer;

[0012] If so, the native adaptation layer calls the corresponding payment SDK to evoke the third-party payment application to execute payment and wait for the payment result callback; otherwise, the native adaptation layer interacts with the payment SDK in the payment system to generate the payment result.

[0013] Preferably, calling the corresponding payment SDK through the native adaptation layer to invoke the third-party payment application to execute payment, and waiting for the payment result callback, includes:

[0014] The third-party payment application triggers a callback according to a pre-agreed URL Scheme, restarts the payment system, and attaches the payment result to the deep link and sends it to the native adaptation layer. The URL Scheme is parsed by the native adaptation layer to obtain the payment result.

[0015] Preferably, obtaining configuration data of the payment channel from the remote configuration server and displaying the enabled payment channels in the Flutter interface to form a payment channel list includes:

[0016] Sending the configuration data including the payment channel identifier, name, activation status, payment parameters, and callback scheme to the remote configuration server;

[0017] Update the payment channel list displayed in the Flutter interface according to the configuration data.

[0018] Preferably, updating the Flutter interface for display according to the payment result includes:

[0019] Render a corresponding prompt page in the Flutter interface according to the payment result for display, wherein the payment result includes payment success, payment failure or payment cancellation.

[0020] Preferably, the payment SDK includes Alipay payment SDK, WeChat payment SDK and UnionPay payment SDK.

[0021] To achieve the above objectives, the present invention also provides a universal payment device based on the Flutter cross-platform framework, which is implemented based on the payment system built by the Flutter framework, and includes:

[0022] A configuration acquisition unit, configured to acquire configuration data of payment channels from a remote configuration server when detecting that the payment system is started, and display the enabled payment channels in a Flutter interface to form a payment channel list;

[0023] a payment request unit, configured to receive a request from a user selecting a target payment channel from the payment channel list and initiate a payment request, wherein the payment request includes order information and a payment channel identifier;

[0024] A payment execution unit, configured to send the payment request to a matching native adaptation layer through a pre-established platform channel, so that the native adaptation layer calls a corresponding payment SDK according to the payment channel identifier to perform a payment operation;

[0025] A result receiving unit is configured to receive the payment result returned by the native adaptation layer through the platform channel, and update the Flutter interface for display according to the payment result.

[0026] To achieve the above objectives, the present invention also provides a universal payment system based on the Flutter cross-platform framework, the payment system comprising:

[0027] The Flutter front-end layer includes the Flutter interface of the payment center and the Flutter payment module. It is used to display the payment channel list to users, handle user operations, and interact with the native adaptation layer through platform channels.

[0028] The native adaptation layer, including the Android native layer and the iOS native layer, is used to receive the payment request sent by the Flutter front-end layer, call the corresponding payment SDK to perform the payment operation, and call back the payment result to the Flutter front-end layer;

[0029] The remote configuration server is used to store the configuration data of the payment channel and send the configuration data of the enabled payment channel to the Flutter front-end layer according to the configuration acquisition request of the Flutter front-end layer.

[0030] In order to achieve the above objectives, the present invention also proposes a universal payment device based on the Flutter cross-platform framework, including a processor, a memory, and a computer program stored in the memory, wherein the computer program is executed by the processor to implement the steps of a universal payment method based on the Flutter cross-platform framework as described in the above embodiment.

[0031] To achieve the above objectives, the present invention also proposes a computer-readable storage medium, on which a computer program is stored. The computer program is executed by a processor to implement the steps of a universal payment method based on the Flutter cross-platform framework as described in the above embodiment.

[0032] Beneficial effects:

[0033] The above solution, built on the Flutter framework, implements payment logic for both Android and iOS platforms, eliminating duplicate development for different platforms, significantly reducing development and maintenance workload and costs, and enabling unified cross-platform payment. Furthermore, leveraging Flutter's high performance and high fidelity, the payment process is smooth and the interface is responsive, enhancing the user experience. Upon startup, the payment system retrieves payment channel configuration data from a remote server, allowing for flexible activation and deactivation of payment channels, quickly adapting to payment business changes without requiring new application releases and improving operational efficiency. This also prevents subsequent users from using deactivated payment channels, reducing the likelihood of payment failures and improving the user experience. Separating the payment logic from the native adaptation layer isolates it from platform differences, facilitating subsequent expansion and maintenance, and enhancing system stability and scalability.

[0034] The native adaptation layer determines whether to jump to a third-party payment application, flexibly supporting payment channels that require jumping to external applications (such as Alipay and WeChat Pay) and channels that complete payment directly within the application (such as UnionPay), meeting diverse payment needs; and, whether jumping to an external payment application or completing payment within the payment system, all interact through the native adaptation layer and platform channels, achieving standardization and unification of the payment process and reducing development complexity.

[0035] Utilizing URL Scheme and deep linking technology, we ensure that after a third-party payment application completes a payment, the payment result is accurately and reliably returned to the payment system, avoiding issues such as loss of payment results or delayed notification, and improving the robustness and reliability of the payment process. By parsing the URL Scheme through a native adaptation layer and strictly validating the payment result data, we prevent malicious calls and data tampering, ensuring payment security.

[0036] By obtaining detailed configuration data of payment channels from a remote configuration server, including payment channel identifiers, names, and activation status, centralized management and configuration of payment channels is achieved, facilitating unified management and adjustment of payment channel policies by operators. The payment channel list in the Flutter interface is dynamically updated based on the configuration data, allowing adjustment of the display and activation status of payment channels without modifying application code. This enables applications to quickly respond to business changes and improves the flexibility and adaptability of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0038] Figure 1 A schematic diagram of a universal payment method based on the Flutter cross-platform framework provided in one embodiment of the present invention.

[0039] Figure 2 A schematic diagram of a specific payment process provided by an embodiment of the present invention.

[0040] Figure 3 A schematic diagram of receiving third-party payment results using deep linking according to an embodiment of the present invention.

[0041] Figure 4 A schematic diagram of the overall architecture of a payment system provided in another embodiment of the present invention.

[0042] Figure 5 A schematic structural diagram of a universal payment device based on the Flutter cross-platform framework is provided in accordance with another embodiment of the present invention.

[0043] The realization of the objectives of the invention, the functional features and advantages will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0044] In order to make the purpose, technical solutions and advantages of the embodiments of the present invention clearer, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention. Therefore, the following detailed description of the embodiments of the present invention provided in the drawings is not intended to limit the scope of the invention for which protection is sought, but merely represents selected embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0045] The present invention is described in detail below with reference to the embodiments.

[0046] Existing technical solutions include native multi-channel SDK integration, aggregated payment SDK / SDK+H5 hybrid solutions. Among them, native multi-channel SDK integration includes:

[0047] Android uses PackageManager#getPackageInfo to detect whether the corresponding app is installed and calls the third-party SDK or Scheme to jump;

[0048] iOS detects and redirects to openURL through UIApplication.canOpenURL, and the callback is handled in application:openURL:options:;

[0049] The converged payment SDK / SDK+H5 hybrid solution includes:

[0050] Some third-party aggregated payment services provide a unified SDK that encapsulates multi-platform logic internally;

[0051] H5 Checkout: Unified display of multiple channel QR codes or links, users scan the code or jump to the H5 payment page.

[0052] The above solution has the following main problems:

[0053] Repeated development: iOS and Android need to independently implement the same business logic, resulting in a large amount of code;

[0054] Complex maintenance: Adding or removing payment channels or changing protocols requires modifying multiple terminal codes separately;

[0055] Inconsistent UI experience: The styles of the native and H5 versions are different, and the switching is noticeable;

[0056] Poor scalability: When adding new channels, the Scheme / SDK must be registered in the native layer, which is inefficient;

[0057] Security risks: Signature and verification logic is scattered in multiple locations, making it prone to errors.

[0058] To this end, the present invention aims to address the shortcomings of the above-mentioned existing solutions and provide a universal payment method based on the Flutter cross-platform framework to improve development efficiency and user experience. It can support universal payment solutions for both Android and iOS with a set of code under the Flutter framework, and realize the unified integration of multiple payment channels. That is,

[0059] Unified payment logic across platforms: This eliminates duplication of payment code on Android and iOS, allowing business logic to be developed once and run on both platforms.

[0060] Standardized payment result callback mechanism: Provides a universal payment method to obtain payment results from various payment channels, ensuring that the results of third-party payment can be reliably transmitted back to the Flutter front-end layer.

[0061] Dynamic configuration and expansion of payment channels: By remotely issuing configurations, payment channels can be flexibly added, deleted, and parameter updated without having to release new versions of the application.

[0062] Consistent user interface and interactive experience: All payment-related pages are uniformly presented by the Flutter front-end layer, ensuring consistent interface style and interactive experience across different platforms and optimizing the smoothness and security of the payment process.

[0063] Reference Figure 1 The figure shows a flow diagram of a universal payment method based on the Flutter cross-platform framework provided by one embodiment of the present invention. In this embodiment, the method is implemented based on the payment system built by the Flutter framework. The method includes:

[0064] S11, when detecting that the payment system is started, obtaining configuration data of the payment channel from the remote configuration server, and displaying the enabled payment channels in the Flutter interface to form a payment channel list;

[0065] S12, receiving a request from a user to select a target payment channel from the payment channel list and initiate a payment request, wherein the payment request includes order information and a payment channel identifier;

[0066] S13, sending the payment request to the matching native adaptation layer through the pre-established platform channel, so that the native adaptation layer calls the corresponding payment SDK according to the payment channel identifier to perform the payment operation;

[0067] S14: Receive the payment result returned by the native adaptation layer through the platform channel, and update the Flutter interface for display according to the payment result.

[0068] In this embodiment, when the payment system starts, it obtains the configuration data of the payment channel from the remote server and presents a list of available payment methods on the Flutter interface. The user selects a payment channel and initiates a payment request. The Flutter layer sends the payment request to the native adaptation layer through MethodChannel. The native adaptation layer calls the corresponding payment SDK to execute the payment. When the payment is completed, it obtains the payment result and returns it to the Flutter layer through MethodChannel. Finally, the Flutter layer updates the Flutter interface to notify the user of the success or failure of the payment. This application abstracts the payment function into a universal payment center module, providing a unified payment request interface and callback events to the outside world. Internally, it connects to different payment channels through modular adapters. This architectural design ensures the loose coupling and scalability of the system.

[0069] The payment system obtains configuration data from a remote server and adjusts its behavior based on the configuration data without having to release an update to the application. Remote configuration can be achieved by requesting a configuration file in JSON or other formats through the network. By sending the configuration data of the payment channel through the remote configuration server, the payment system can dynamically adjust the supported payment methods without updating the client. For example, the remote server maintains a JSON configuration that lists each payment channel and its parameters. When the payment system starts, the configuration data is requested and cached. The local payment center module decides which payment options to display based on this data and uses the relevant parameters for SDK initialization or interface calls. An example configuration JSON structure is as follows:

[0070]

[0071]

[0072] In the above JSON example, the channels array contains information about several payment channels. Each payment channel has fields: id (payment channel identifier, used for logic analysis in the Flutter and native layers), name (the name displayed to the user), enabled (whether the payment channel is enabled for remote control), and other required payment parameters. For example, the Alipay and WeChat payment channels are both configured with the callback scheme "myapp" (the native layer must configure the corresponding scheme permissions in the Info.plist or AndroidManifest) and their respective appIds. In this example, the "enabled" value for the UnionPay payment channel is false, indicating that it is not currently enabled. The payment system can periodically or in specific scenarios pull this configuration data from a remote server to update the local payment channel list, enabling dynamic expansion or disabling of certain payment methods on demand without requiring new releases. When the remote server sends configuration data changes, the Flutter front-end layer receives the new configuration data and instantly refreshes the payment options on the Flutter interface, ensuring that operational adjustments take effect immediately.

[0073] A payment channel refers to a specific payment method or method, and can also be understood as a payment service provider. Examples include Alipay, WeChat Pay, UnionPay QuickPass, Apple Pay, and other payment channels. Each payment channel typically has its own SDK or interface specifications.

[0074] Furthermore, in step S11, the configuration data of the payment channel is obtained from the remote configuration server, and the enabled payment channels are displayed in the Flutter interface to form a payment channel list, including:

[0075] S11-1, sending the configuration data including the payment channel identifier, name, activation status, payment parameters and callback scheme to the remote configuration server;

[0076] S11-2, update the payment channel list displayed in the Flutter interface according to the configuration data.

[0077] Reference Figure 2As shown, when the payment system is initialized or enters the payment center of the payment system (which encapsulates the access logic of multiple payment channels and provides a consistent interface for applications to initiate payment requests and obtain results), the currently supported payment channels and their configurations (such as the enablement status and parameters of payment channels such as "Alipay" and "WeChat Pay") are obtained from the remote configuration server, and then the list of payment methods for available payment channels is dynamically displayed on the Flutter page. After the user selects a payment method and submits the payment, the Flutter payment logic calls the corresponding interface of the native adaptation layer through the pre-established platform channel (MethodChannel), and passes the payment request including the order information and the selected payment channel identifier to the native adaptation layer.

[0078] Furthermore, in step S13, the payment request is sent to the matching native adaptation layer through the pre-established platform channel, so that the native adaptation layer calls the corresponding payment SDK according to the payment channel identifier to perform the payment operation, including:

[0079] S13-1, determining, by the native adaptation layer, based on the payment channel identifier, whether to jump to a third-party payment application;

[0080] S13-2, if yes, the native adaptation layer calls the corresponding payment SDK to invoke the third-party payment application to execute payment, and waits for the payment result callback; otherwise, the native adaptation layer interacts with the payment SDK in the payment system to generate the payment result.

[0081] Furthermore, in step S13-1, calling the corresponding payment SDK through the native adaptation layer to invoke the third-party payment application to execute payment and waiting for the payment result callback includes:

[0082] The third-party payment application triggers a callback according to a pre-agreed URL Scheme, restarts the payment system, and attaches the payment result to the deep link and sends it to the native adaptation layer. The URL Scheme is parsed by the native adaptation layer to obtain the payment result.

[0083] Furthermore, the URL Scheme is parsed by the native adaptation layer to obtain the payment result, including:

[0084] When the native adaptation layer is an Android platform, the URL Scheme is captured through the onNewIntent method and the payment result parameter in the URL Scheme is parsed to obtain the payment result;

[0085] When the native adaptation layer is an iOS platform, the URL Scheme is captured through the application(_:open:options:) method and the payment result parameter in the URL Scheme is parsed to obtain the payment result.

[0086] Furthermore, the payment SDK includes Alipay payment SDK, WeChat payment SDK and UnionPay payment SDK.

[0087] Furthermore, in step S14, updating the Flutter interface for display according to the payment result includes:

[0088] Render a corresponding prompt page in the Flutter interface according to the payment result for display, wherein the payment result includes payment success, payment failure or payment cancellation.

[0089] In this embodiment, for payments that need to jump to a third-party App (for example, launching Alipay or WeChat to complete the payment), the native adaptation layer will call up the corresponding third-party payment application and wait for the payment result callback; for payments completed within the current payment system (for example, calling the UnionPay SDK to directly complete the deduction), the native adaptation layer directly interacts with the payment SDK and obtains the payment result. In either case, after the payment is completed, the native adaptation layer will obtain the payment result (success, failure, or cancellation, etc.), and then pass the payment result back to the Flutter layer through MethodChannel. After receiving the payment result, the Flutter layer updates the payment center UI (Flutter interface), displays the payment success or failure status to the user, and performs subsequent processing (such as notifying the business server of the order status, etc.).

[0090] A payment SDK is a library or suite provided by a third-party payment platform. Developers integrate the SDK and can then call its functions within their applications to complete payments. For example, the Alipay SDK and WeChat Pay SDK both include a payment interface, signature verification, and result callback functionality. The native adaptation layer in this embodiment calls the corresponding payment SDK for each payment channel to perform the actual payment operation.

[0091] For the case of calling third-party payment applications, DeepLink technology is used to ensure that the payment results can be returned to the payment system. Figure 3As shown, after the Flutter layer invokes the external payment app through the native adaptation layer, the user completes the payment in the third-party payment app. The third-party payment app triggers a callback according to the pre-agreed URL Scheme, restarts the original payment system, and appends the payment result to the DeepLink (for example, myapp: / / payresult?result=success). The native adaptation layer captures the URL passed in when the payment system is invoked, parses the payment result information from it, and then notifies the Flutter payment center module of the Flutter layer of the payment result through the MethodChannel. The Flutter layer updates the Flutter interface accordingly and completes subsequent business processes. The DeepLink mechanism ensures that regardless of whether the payment process jumps to the external payment application, the payment result can be uniformly transmitted back to the Flutter layer for processing.

[0092] Deep linking is a technology that allows users to directly access internal pages within a mobile app via a specific URL or URI. Deep linking is a linking technology that takes users directly from an external webpage or app to a specific page within the app. In this example, deep linking is used to call a preset URL to reopen the app after a payment is completed with a third-party payment app, along with the payment result parameter, thereby enabling cross-app information transfer. Common forms include custom URL schemes and universal links.

[0093] MethodChannel is a channel mechanism provided by Flutter for communicating with native platforms. Through MethodChannel, the Dart code of the Flutter application can call the methods of the native platform, and the native code can also return the execution results to Flutter. In short, the MethodChannel of the Flutter layer allows method call messages to be sent, and the MethodChannel of the native (Android / iOS) layer allows method calls to be received and the results to be sent back. This embodiment uses MethodChannel to implement command and data interaction between Flutter and the payment adapters of each platform.

[0094] Reference Figure 4 The figure shows the overall architecture of a universal payment system based on the Flutter cross-platform framework provided by another embodiment of the present invention. In this embodiment, the payment system includes:

[0095] The Flutter front-end layer includes the Flutter interface of the payment center and the Flutter payment module. It is used to display the payment channel list to users, handle user operations, and interact with the native adaptation layer through platform channels.

[0096] The native adaptation layer, including the Android native layer and the iOS native layer, is used to receive the payment request sent by the Flutter front-end layer, call the corresponding payment SDK to perform the payment operation, and call back the payment result to the Flutter front-end layer;

[0097] The remote configuration server is used to store the configuration data of the payment channel and send the configuration data of the enabled payment channel to the Flutter front-end layer according to the configuration acquisition request of the Flutter front-end layer.

[0098] In this embodiment, the payment system mainly includes the Flutter front-end layer, the native adaptation layer and the remote configuration service. Among them, the Flutter front-end layer includes the UI interface of the payment center and the Flutter payment logic module, which is responsible for displaying payment options to users, processing user operations, and interacting with the native adaptation layer through the platform channel; the native adaptation layer is implemented in the Android native layer and the iOS native layer respectively, and is used to receive instructions from the Flutter layer and call the corresponding platform payment SDK (such as Alipay payment SDK, WeChat payment SDK, etc.) to perform payment operations, and at the same time call back the payment results to the Flutter layer; the remote configuration service is used to store and distribute the configuration data of the payment channel, such as which payment methods are supported, the payment parameters of each payment channel (App ID, private key, etc.) and the payment page configuration, etc., for the application to dynamically obtain at runtime.

[0099] First, the Flutter front-end layer establishes communication with the native adaptation layer through MethodChannel. In the Dart code of the Flutter layer, you can create a MethodChannel and call the platform method. The code is as follows:

[0100]

[0101] The above Flutter code defines a platform channel named "payment_center" through MethodChannel('payment_center') and calls invokeMethod('pay',args) to send the payment request to the native layer (where args contains the payment channel identifier and order information, etc.). After the invokeMethod call, the Flutter layer will wait for the native layer to return the result (synchronous waiting is achieved through await in this embodiment). After the native layer completes the processing, it should return a result object to Flutter, and Flutter can read the payment result status in the result and perform UI updates or business processing.

[0102] The native adaptation layer needs to process the "pay" method call initiated by Flutter. The following is an implementation example on the Android platform (using Java):

[0103]

[0104] Note: pendingResult is used to cache the Dart-side callback handle in asynchronous scenarios;

[0105] startSdkPay(...) represents the jump to different channel SDKs;

[0106] onNewIntent parses the DeepLink (such as myapp: / / pay?result=success) and calls success() to return.

[0107] Specifically, the Android code sets up a MethodChannel named "payment_center" in MainActivity. When receiving a call.method == "pay" from Flutter, it determines the payment channel (for example, "alipay" or "wxpay") based on the passed-in channel parameter and then calls the corresponding payment SDK. Since Alipay and WeChat Pay often require external app processing, pendingResult is used to temporarily store the result callback handle passed by Flutter to return asynchronous results to Flutter. When the user completes the payment and returns to the app (Android receives the previously registered URL Scheme via onNewIntent), the payment result is parsed in onNewIntent and sent back to Flutter via the previously saved pendingResult.success(...). From Flutter's perspective, the previously called invokeMethod returns the passed-in resultData, thus obtaining the payment result.

[0108] For the iOS platform, the native adaptation layer can adopt a similar approach. The following is an implementation example in Swift:

[0109]

[0110] Note: pendingResult is used to cache the FlutterResult on the Flutter side, waiting for the external app to return;

[0111] startSdkPay(_,_) means to call the corresponding payment SDK;

[0112] Register the URL Scheme (myapp: / / …) in Info.plist to ensure that you can return to this app after the payment is completed;

[0113] If the App is recycled by the system and cold restarted, use onPayResult to actively push the result to avoid result loss.

[0114] Specifically, the iOS code creates a FlutterMethodChannel (name: "payment_center") corresponding to Flutter when the app starts, and handles payment requests from Flutter in setMethodCallHandler. Similarly, the Alipay or WeChat iOS SDK is called based on the channelId. If a callback from an external app is required, pendingResult is used to store the FlutterResult for later invocation. The iOS DeepLink callback is captured by implementing the application(_:open:options:) method. When the URL scheme used to open the app matches the pre-defined myapp, the payment result parameter in the URL is parsed and the result dictionary is returned to Flutter via pendingResult?(["result":payResult]). If pendingResult is empty (for example, if the app is killed by the system and then relaunched via the scheme, with no pending result pending), the code demonstrates an alternative approach: directly using methodChannel.invokeMethod to notify Flutter of the payment result, which can be handled uniformly within the Flutter event listener. This ensures that payment result notifications are not lost regardless of whether the app is in the foreground or is restarted.

[0115] Reference Figure 5 FIG2 is a schematic diagram showing the structure of a universal payment device based on the Flutter cross-platform framework provided by one embodiment of the present invention.

[0116] In this embodiment, the device is implemented based on a payment system built on the Flutter framework. The device 20 includes:

[0117] The configuration acquisition unit 21 is configured to acquire configuration data of the payment channels from a remote configuration server when detecting that the payment system is started, and to display the enabled payment channels in the Flutter interface to form a payment channel list;

[0118] a payment request unit 22, configured to receive a request from a user selecting a target payment channel from the payment channel list and initiate a payment request, wherein the payment request includes order information and a payment channel identifier;

[0119] The payment execution unit 23 is configured to send the payment request to the matching native adaptation layer through a pre-established platform channel, so that the native adaptation layer calls the corresponding payment SDK according to the payment channel identifier to perform the payment operation;

[0120] The result receiving unit 24 is configured to receive the payment result returned by the native adaptation layer through the platform channel, and update the Flutter interface for display according to the payment result.

[0121] Each unit module of the device 20 can respectively execute the corresponding steps in the above method embodiment, so each unit module will not be described in detail here. Please refer to the description of the corresponding steps above for details.

[0122] The device can be used Figure 5 The structure of the embodiment can be executed accordingly. Figure 1 The technical solution of the method embodiment shown has similar implementation principles and technical effects. For details, please refer to the relevant records in the above embodiments and will not be repeated here.

[0123] An embodiment of the present invention further provides a universal payment device based on the Flutter cross-platform framework, which includes the universal payment device based on the Flutter cross-platform framework described above. Furthermore, the device includes: a device with a camera function, such as a mobile phone, a digital camera, or a tablet computer, or a device with an image processing function, or a device with an image display function. The device may include components such as a memory, a processor, an input unit, a display unit, and a power supply.

[0124] Among them, the memory can be used to store software programs and modules, and the processor executes various functional applications and data processing by running the software programs and modules stored in the memory. The memory may mainly include a program storage area and a data storage area, wherein the program storage area can store an operating system, an application required for at least one function (such as an image playback function, etc.), etc.; the data storage area can store data created according to the use of the device, etc. In addition, the memory may include a high-speed random access memory, and may also include a non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage device. Accordingly, the memory may also include a memory controller to provide the processor and the input unit with access to the memory.

[0125] The input unit can be used to receive input digital, character, or image information, and generate keyboard, mouse, joystick, optical, or trackball signal input related to user settings and function control. Specifically, the input unit of this embodiment includes not only a camera, but also a touch-sensitive surface (such as a touch display) and other input devices.

[0126] The display unit can be used to display information input by the user or information provided to the user and various graphical user interfaces of the device, which can be composed of graphics, text, icons, videos and any combination thereof. The display unit may include a display panel. Optionally, the display panel can be configured in the form of an LCD (Liquid Crystal Display), an OLED (Organic Light-Emitting Diode), etc. Furthermore, the touch-sensitive surface can cover the display panel. When the touch-sensitive surface detects a touch operation on or near it, it is transmitted to the processor to determine the type of touch event. The processor then provides a corresponding visual output on the display panel based on the type of touch event.

[0127] The embodiment of the present invention further provides a computer-readable storage medium, which may be a computer-readable storage medium included in the memory in the above embodiment; or a computer-readable storage medium that exists independently and is not assembled into a device. The computer-readable storage medium stores at least one instruction, which is loaded and executed by a processor to implement Figure 1 The universal payment method based on the Flutter cross-platform framework is shown. The computer-readable storage medium can be a read-only memory, a disk or an optical disk, etc.

[0128] It should be noted that the various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. For similar or identical parts between the various embodiments, reference can be made to each other. For the apparatus embodiments, device embodiments, and storage medium embodiments, since they are generally similar to the method embodiments, their descriptions are relatively simple. For relevant parts, reference can be made to the descriptions of the method embodiments.

[0129] Furthermore, in this document, the terms "comprises," "comprising," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus that includes a list of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not preclude the presence of additional identical elements in the process, method, article, or apparatus that includes the element.

[0130] While the foregoing description shows and describes preferred embodiments of the present invention, it should be understood that the present invention is not limited to the forms disclosed herein and should not be construed as excluding other embodiments. Rather, the present invention can be used in various other combinations, modifications, and environments, and can be modified within the scope of the present invention by the teachings herein or by techniques or knowledge in the relevant art. Modifications and variations made by those skilled in the art without departing from the spirit and scope of the present invention are intended to be within the scope of the appended claims.

Claims

1. A universal payment method based on the Flutter cross-platform framework, characterized in that: The method is implemented based on a payment system built on the Flutter framework, and includes: When detecting that the payment system is started, obtaining configuration data of the payment channel from the remote configuration server, and displaying the enabled payment channels in the Flutter interface to form a payment channel list; receiving a user selecting a target payment channel from the payment channel list and initiating a payment request, wherein the payment request includes order information and a payment channel identifier; Sending the payment request to the matching native adaptation layer through a pre-established platform channel, so that the native adaptation layer calls the corresponding payment SDK according to the payment channel identifier to perform the payment operation; Receive the payment result returned by the native adaptation layer through the platform channel, and update the Flutter interface for display according to the payment result.

2. A universal payment method based on the Flutter cross-platform framework according to claim 1, characterized in that: The step of sending the payment request to a matching native adaptation layer through a pre-established platform channel, so that the native adaptation layer calls a corresponding payment SDK according to the payment channel identifier to perform a payment operation, includes: Determining whether to jump to a third-party payment application according to the payment channel identifier by the native adaptation layer; If so, the native adaptation layer calls the corresponding payment SDK to evoke the third-party payment application to execute payment and wait for the payment result callback; otherwise, the native adaptation layer interacts with the payment SDK in the payment system to generate the payment result.

3. A universal payment method based on the Flutter cross-platform framework according to claim 2, characterized in that: The calling of the corresponding payment SDK by the native adaptation layer to invoke the third-party payment application to execute payment and waiting for the payment result callback includes: The third-party payment application triggers a callback according to a pre-agreed URL Scheme, restarts the payment system, and attaches the payment result to the deep link and sends it to the native adaptation layer. The URL Scheme is parsed by the native adaptation layer to obtain the payment result.

4. A universal payment method based on the Flutter cross-platform framework according to claim 1, characterized in that: The configuration data of the payment channel is obtained from the remote configuration server, and the enabled payment channels are displayed in the Flutter interface to form a payment channel list, including: Sending the configuration data including the payment channel identifier, name, activation status, payment parameters, and callback scheme to the remote configuration server; Update the payment channel list displayed in the Flutter interface according to the configuration data.

5. A universal payment method based on the Flutter cross-platform framework according to claim 1, characterized in that: Updating the Flutter interface for display according to the payment result includes: Render a corresponding prompt page in the Flutter interface according to the payment result for display, wherein the payment result includes payment success, payment failure or payment cancellation.

6. A universal payment method based on the Flutter cross-platform framework according to claim 1, characterized in that: The payment SDKs include Alipay Payment SDK, WeChat Payment SDK and UnionPay Payment SDK.

7. A universal payment device based on the Flutter cross-platform framework, characterized in that: The device is implemented based on a payment system built on the Flutter framework, and includes: A configuration acquisition unit, configured to acquire configuration data of payment channels from a remote configuration server when detecting that the payment system is started, and display the enabled payment channels in a Flutter interface to form a payment channel list; a payment request unit, configured to receive a request from a user selecting a target payment channel from the payment channel list and initiate a payment request, wherein the payment request includes order information and a payment channel identifier; A payment execution unit, configured to send the payment request to a matching native adaptation layer through a pre-established platform channel, so that the native adaptation layer calls a corresponding payment SDK according to the payment channel identifier to perform a payment operation; A result receiving unit is configured to receive the payment result returned by the native adaptation layer through the platform channel, and update the Flutter interface for display according to the payment result.

8. A universal payment system based on the Flutter cross-platform framework, characterized by: The payment system includes: The Flutter front-end layer includes the Flutter interface of the payment center and the Flutter payment module. It is used to display the payment channel list to users, handle user operations, and interact with the native adaptation layer through platform channels. The native adaptation layer, including the Android native layer and the iOS native layer, is used to receive the payment request sent by the Flutter front-end layer, call the corresponding payment SDK to perform the payment operation, and call back the payment result to the Flutter front-end layer; The remote configuration server is used to store the configuration data of the payment channel and send the configuration data of the enabled payment channel to the Flutter front-end layer according to the configuration acquisition request of the Flutter front-end layer.

9. A universal payment device based on the Flutter cross-platform framework, characterized in that: The device includes a processor, a memory, and a computer program stored in the memory, wherein the computer program is executed by the processor to implement the steps of a universal payment method based on the Flutter cross-platform framework as described in any one of claims 1 to 6.

Images