Cross-border renminbi payment method and system based on geo-fencing and exchange rate conversion

Abstract

The present application relates to a cross-border RMB payment method and system based on geo-fencing and exchange rate conversion, and relates to the technical field of cross-border mobile payment, which comprises the following steps: obtaining the position of a user; finding the geographical area where the position of the user falls into; finding the corresponding local service mode; generating a user payment code and outputting the same when a preset payment code presentation signal is received; calling a merchant account and collecting the local currency amount when the user payment code is detected to be scanned, converting the local currency amount to obtain a RMB amount, pre-freezing the RMB amount, and outputting a payment confirmation signal; calling the merchant account and obtaining the local currency amount when a merchant payment code is identified, converting the local currency amount to obtain a RMB amount, pre-freezing the RMB amount, and outputting a preset payment confirmation signal; deducting the RMB amount from the user account and transferring the local currency amount to the merchant account when an amount determination signal is received. The present application has the effect of improving the overall cumbersome process of cross-border payment.

Description

Technical Field

[0001] This invention relates to the field of cross-border mobile payment technology, and in particular to a cross-border RMB payment method and system based on geofencing and currency conversion. Background Technology

[0002] With increasingly close economic and trade exchanges between China and foreign countries, outbound business travel is becoming more frequent. Cross-border payment, as an important supporting measure for business travel, can ensure the smooth completion of various overseas consumer transactions, while facilitating enterprises to manage travel expenses and conduct financial accounting, providing strong support for enterprises' overseas business operations, daily travel and office work.

[0003] Currently, cross-border payment methods for outbound business travel are quite fragmented. When domestic mobile payments are extended to overseas scenarios, users typically manually switch to the corresponding regional service, and manually verify and convert currencies during the transaction; some people also choose to exchange foreign currency cash in advance to complete their purchases.

[0004] Regarding the aforementioned technologies, the transaction interface often displays foreign currencies, requiring users to manually switch service areas and manually calculate currencies. In some scenarios, it is also necessary to exchange foreign currencies in advance, making the overall cross-border payment process cumbersome and leaving room for improvement. Summary of the Invention

[0005] To improve the cumbersome overall process of cross-border payments, this invention provides a cross-border RMB payment method and system based on geofencing and currency conversion.

[0006] In a first aspect, the present invention provides a cross-border RMB payment method based on geofencing and currency conversion, employing the following technical solution: Cross-border RMB payment methods based on geofencing and currency conversion include: Step 1: Obtain user location; Step 2: Locate the geographic area where the user's location falls within the preset geofencing map; Step 3: Based on the geographical region, find the corresponding local service mode in the preset geographical service database. The local service mode includes payment code generator, real-time exchange rate source and local intermediary fund account. Step 4: When the preset payment code display signal is received, the payment code generator is invoked to generate and output the user's payment code; Step 5: When the scan of the user's payment code is detected, retrieve the merchant's account and collect the local currency amount entered by the merchant. Call the real-time exchange rate source to convert the local currency amount to the corresponding RMB amount, pre-freeze the RMB amount and output the preset payment confirmation signal. Step 6: When the merchant's QR code is detected, retrieve the merchant's account and obtain the amount of local currency to be paid. Use the real-time exchange rate source to convert the local currency amount to the corresponding RMB amount. Pre-freeze the RMB amount and output a preset payment confirmation signal. Step 7: When the user confirms the amount, deduct the RMB amount from the preset user account and transfer the local currency amount from the local transfer fund account to the merchant account.

[0007] By adopting the above technical solution, the user's location is first obtained and matched with the geographical region, and the corresponding local service mode is retrieved; the two scenarios of the user presenting a payment code and having it scanned and the user scanning the merchant's payment code are distinguished, and the currency conversion, fund pre-freezing and waiting for user confirmation are completed; after final confirmation, RMB is deducted from the user's account, and the local currency is transferred to the merchant from the local transit fund account. This solves the problem that users need to manually switch service regions and manually calculate currencies, reduces the manual operation cost in the cross-border payment process, and simplifies the payment process.

[0008] Optionally, a method for verifying user location may also be included, which includes: Step 10: Obtain the user's cross-border travel information and parse the user's destination from the cross-border travel information; Step 11: Locate the geographic area where the user's destination falls within the geofencing map; Step 12: If the destination geographic region is the same as the geographical region, output the geographic region; Step 13: If the destination geographical region is different from the geographic region, output the destination geographical region as the geographic region.

[0009] By adopting the above technical solution, combining cross-border travel information to analyze the user's destination, matching the corresponding destination area; comparing the user's location geographical area, if they are inconsistent, the destination area is used as the standard to complete the location correction, which solves the problem of geographical area matching deviation that is easy to occur when relying solely on the user's terminal positioning, and achieves the effect of correcting the user's location by combining cross-border travel information.

[0010] Optional, also includes: Step 14: Retrieve the merchant's historical transaction records based on the merchant account; Step 15: Search for recent transaction records from historical transaction records according to the preset time period; Step 16: Analyze the trading currencies and the number of transactions corresponding to each currency in recent transaction records; Step 17: Count the types of currencies traded. If there are more than 1 types of currencies, select the currency with the most transactions and use it as the preferred currency. Step 18: Find the corresponding reference geographical area based on the preferred currency; Step 19: If the reference geographic region and the geographic region are inconsistent, find the corresponding reference service mode in the geographic service database based on the reference geographic region, and update the local service mode to the reference service mode.

[0011] By adopting the above technical solution, the merchant's recent transaction records are retrieved, the transaction currencies and transaction frequency are counted, the preferred currency is selected and matched with the corresponding reference geographical area; if the reference geographical area and the geographical area are inconsistent, the corresponding reference service mode is switched, which solves the problem that when the location drifts in the border area, the payment service based on the geographical area may not be compatible with the merchant's commonly used currency, and achieves a dynamic payment effect that fits the merchant's payment habits.

[0012] Optionally, methods for retrieving a merchant's historical transaction records based on the merchant account include: Step 140: Divide the user's activity range into a preset radius range, with the user's location as the center; Step 141: Locate the geographical areas where the user's activity range intersects in the geofence map; Step 142: Count the number of geographical areas where user activity ranges intersect; Step 143: If the number of regions is greater than 1, retrieve the merchant's historical transaction records based on the merchant account.

[0013] By adopting the above technical solution, the user's activity range is defined by the user's location and radius, and the number of geographical areas intersecting with the user's activity range is counted. When multiple areas intersect, the merchant's historical transaction records are retrieved. This solves the problem that indiscriminate retrieval of merchant transaction records when the user is at the border will easily increase the computational burden, and achieves the effect of pre-screening by utilizing the intersection of regions.

[0014] Optionally, if the number of regions is greater than 1, the methods for retrieving a merchant's historical transaction records based on the merchant account include: Step 1430: Define the geographical area where the user activity ranges intersect as the area to be determined; Step 1431: Search for the legal tender corresponding to the region to be determined in the preset regional currency database; Step 1432: Count the legal types of fiat currency; Step 1433: If the number of legal categories is no more than 1, the local service mode is used directly and the geographical area corresponding to the area to be determined is regarded as the same geographical area; Step 1434: If the number of legal categories is greater than 1, retrieve the merchant's historical transaction records based on the merchant account.

[0015] By adopting the above technical solution, intersecting geographical areas are treated as areas to be determined. Their legal currencies and legal types are queried and counted. Merchant transaction records are only retrieved when the number of legal types is greater than 1. This solves the problem of increasing the computational burden when retrieving merchant transaction records when intersecting geographical areas all use the same legal currency. Intersecting geographical areas that all use the same legal currency are classified into the same geographical area, which saves computing resources and simplifies the processing logic of boundary scenes.

[0016] Optionally, it also includes a preferred method for the transaction currency, which includes: Step 170: If RMB is not among the transaction currencies, then select the transaction currency with the most transactions and use it as the preferred currency, and continue to execute steps 18 to 19. Step 171: If RMB is present in the transaction currency and the number of transactions exceeds the preset threshold, it is determined that the merchant accepts RMB payment, and RMB is used as the preferred currency to replace the transaction currency with the most transactions. Step 172: Use the real-time exchange rate source to convert the local currency amount entered by the merchant or the local currency amount to be paid into RMB. Step 173: Pre-freeze the RMB amount and output a payment confirmation signal; Step 174: When the user confirms the amount, deduct the RMB amount from the user's account and directly pay it to the RMB settlement account associated with the merchant's account.

[0017] By adopting the above technical solution, it is determined whether there are RMB transactions in the merchant's recent transaction records. If there are no RMB transactions, the original process is followed. When the number of RMB transactions reaches the target, RMB is the preferred currency, the amount is converted and paid directly to the merchant. This solves the problem of process redundancy when using foreign currency transfer when the merchant can reliably receive RMB, avoids unnecessary merchant history queries, and achieves the effect of simplifying the payment process based on the merchant's ability to receive RMB payments.

[0018] Optionally, it also includes a handling method if the number of regions is equal to 1, the method comprising: Step 1435: Search for the local official currency of the geographical region in the preset regional currency database and count the official types corresponding to the local official currency; Step 1436: If the number of official types is greater than 1, proceed to steps 14 to 17 to obtain the preferred currency; Step 1437: If the preferred currency falls into the local official currency, the preferred currency will be used as the default payment currency for the merchant account, and the default payment amount corresponding to the default payment currency will be calculated based on the merchant exchange rate provided by the merchant account. Step 1438: Call the real-time exchange rate source to convert the default payment amount into the corresponding RMB amount, pre-freeze the RMB amount and output a payment confirmation signal; Step 1439: When the user confirms the amount, deduct the RMB amount from the user's account and transfer the default payment amount from the local transit funds account corresponding to the default payment currency to the merchant's account.

[0019] By adopting the above technical solution, when a user's activity range corresponds to only a single geographical area, the system first queries the official currency types of that area. If multiple official currencies exist, the preferred currency is determined based on the merchant's recent transaction records and set as the default payment currency. The amount is then converted sequentially using the merchant's exchange rate and the real-time exchange rate to complete the pre-freezing of funds and the final transfer. This solves the problem that when multiple official currencies exist in a single geographical area, users may not be clear about the merchant's preferred currency, which could lead to payment failure or additional exchange costs. It achieves the effect of eliminating the need for users to select a currency when multiple official currencies exist in a single geographical area.

[0020] Optionally, it also includes a method for handling situations where the preferred currency falls into the local official currency and the local official currency includes Renminbi, the method including: Step 14370: If the preferred currency is not RMB, proceed to steps 1435 to 1439; Step 14371: If the preferred currency is RMB, convert the local currency amount into the RMB amount corresponding to the preferred currency based on the merchant exchange rate provided by the merchant account, pre-freeze the RMB amount, and output a payment confirmation signal. Step 14372: When the user confirms the amount, deduct the RMB amount from the user's account and pay it directly to the RMB settlement account associated with the merchant's account.

[0021] By adopting the above technical solution, when the local official currency in a geographical area includes RMB, if the preferred currency is not RMB, the regular transit payment process will be followed; if the preferred currency is RMB, the amount will be converted according to the merchant's exchange rate, pre-frozen, and then the RMB amount will be transferred directly after confirmation. This solves the problem of cumbersome processes caused by foreign currency transit when the local official currency is RMB and the merchant prefers RMB, thus achieving the effect of reducing payment costs and improving user experience.

[0022] Optionally, methods for obtaining the amount to be paid in local currency include: Step 60: When the signal to capture the amount sent by the user is received, control the camera to start capturing the image of the merchant's price tag; Step 61: Perform character recognition on the merchant's price tag image and extract the numerical information as the initial currency amount; Step 62: Output the initial currency amount and the preset numerical confirmation signal; Step 63: When a signal indicating that the value is correct is received from the user, the initial currency amount is output as the local currency amount.

[0023] By adopting the above technical solution, after receiving the amount shooting signal sent by the user, the camera is called to capture the price tag image, the character recognition extracts the amount and gives it to the user for verification. After confirmation that it is correct, the value is used as the amount to be paid in local currency, which solves the problem that it is troublesome and easy to make mistakes when the user has to manually enter the amount.

[0024] Secondly, this invention provides a cross-border RMB payment system based on geofencing and currency conversion, employing the following technical solution: A cross-border RMB payment system based on geofencing and currency conversion includes: The acquisition module is used to obtain user location, local currency amount, and cross-border travel information; A memory for storing the program for the cross-border RMB payment method based on geofencing and currency conversion as described above; The processor loads and executes programs from memory.

[0025] In summary, the present invention has at least one of the following beneficial technical effects: It solves the problem of users needing to manually switch service areas and manually calculate currencies, reduces the manual operation costs in the cross-border payment process, and simplifies the payment process; This solves the problem of increased computational burden caused by retrieving merchant transaction records when intersecting geographical regions all use the same legal currency. It groups intersecting geographical regions that all use the same legal currency into the same geographical region, achieving the effect of saving computing resources and simplifying the processing logic of boundary scenes. This solution addresses the issue that when multiple official currencies exist within a single geographical area, users may be unclear about which currency merchants prefer to accept, potentially leading to payment failures or additional exchange costs. It achieves the effect of eliminating the need for users to select a currency when multiple official currencies exist within a single geographical area. Attached Figure Description

[0026] Figure 1 This is a flowchart of a cross-border RMB payment method based on geofencing and currency conversion in an embodiment of this application; Figure 2 This is a flowchart of the method for retrieving a merchant's historical transaction records based on a merchant account, as described in this application embodiment; Figure 3 This is a flowchart of the processing method when the number of regions is equal to 1 in the embodiments of this application. Detailed Implementation

[0027] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments.

[0028] This invention discloses a cross-border RMB payment method based on geofencing and currency conversion. (See also...) Figure 1 Cross-border RMB payment methods based on geofencing and currency conversion include: Step 1: Obtain user location.

[0029] Users pre-install a payment application on their mobile devices or enable this payment function in a mini-program platform. The payment application or mini-program connects to the backend server of the payment application via the network. These are collectively referred to as payment applications.

[0030] User location refers to the spatial coordinates of the mobile terminal device currently used by the user. The user location is determined by accessing the mobile terminal device's Global Navigation Satellite System (GNSS) positioning function. After the payment application obtains location permissions, it reads latitude and longitude data every certain period of time (e.g., 1 second). This latitude and longitude data constitutes the user's location.

[0031] Step 2: Locate the geographic area where the user's location falls within the preset geofencing map.

[0032] A geofence map is a collection of electronic map data for geofences, containing boundary data for several geographic regions, each corresponding to a country or region (such as Saudi Arabia, the United Arab Emirates, and the Hong Kong Special Administrative Region of China). Specifically, it is constructed as follows: based on the administrative boundaries of countries or regions as defined by international standards (such as ISO 3166 country codes), electronic map boundary data is obtained from authoritative geographic information data sources (such as OpenStreetMap). The complete administrative area of ​​each country or region is considered as a single geographic region, each region is named according to its corresponding country code, and the boundary data of each region is stored in a database as a set of polygonal coordinate points, thus constructing a geofence map.

[0033] A geographic region refers to the area where the user's location is matched with the geofence map. The latitude and longitude coordinates of the user's location are compared with all the preset geographic regions in the geofence map to calculate the inclusion relationship between points and polygons. If the user's location is inside a geographic region, the country code corresponding to that geographic region is output as the identifier of that geographic region; if the user's location falls on the boundary, it is considered to intersect with the adjacent region, and the unique region is selected by referring to the subsequent steps.

[0034] Step 3: Based on the geographic region, find the corresponding local service mode in the preset geographic service database. The local service modes include payment code generator, real-time exchange rate source and local intermediary fund account.

[0035] The geographic service database stores a mapping relationship between geographic regions and local service models. This database is pre-configured by those skilled in the art: for each geographic region, based on its business needs, the parameters of the corresponding payment code generator, the real-time exchange rate source interface address, and the local intermediary funds account information are entered. These three pieces of information constitute the local service model configuration for that geographic region. Associating the country code of each geographic region with its corresponding local service model forms the geographic service database.

[0036] Local service models refer to the essential dataset for cross-border payments within a geographic region, including a payment code generator configured for that region, a real-time exchange rate source, and a local intermediary fund account. The corresponding local service model can be retrieved by querying the geographic service database using the geographic region as an index.

[0037] A payment code generator is a software module that dynamically generates a user's payment code according to the QR code encoding standard of a geographical region. When building a local service model, the payment application retrieves the corresponding payment code generator program file from the payment application's code repository based on the QR code encoding standard used in the target geographical region (e.g., the Mada standard in Saudi Arabia or the internationally accepted EMVCo standard). After deployment, a payment code generator object is instantiated, which is configured with parameters such as the code format, encryption rules, and token validity period for the target geographical region. The code repository stores and manages the source code of all software modules in the payment application development environment. Those skilled in the art pre-write the payment code generator code corresponding to each geographical region and submit it to the code repository.

[0038] A real-time exchange rate source refers to an interface that provides real-time market exchange rate queries between the RMB and a designated foreign currency in a specified geographical region. Each local service mode can be configured with one or more real-time exchange rate sources, each corresponding to one or more official payment currencies supported by that geographical region (e.g., the Hong Kong SAR mode can be configured with two exchange rate sources: CNY / HKD and CNY / USD). The payment application signs a data usage agreement with a third-party exchange rate data service provider (such as Bloomberg, Reuters, or the China Foreign Exchange Trading Center) to obtain access credentials (such as API keys and accounts). Those skilled in the art write the exchange rate query module code based on the interface documentation provided by the service provider, configuring the interface address, request parameter format, and timeout period provided by the service provider to obtain a configuration file. This exchange rate query module is deployed on the payment application server. Upon startup, it reads the interface address and credentials from the configuration file to establish a connection with the data service. Simultaneously, the payment application sets up a scheduled task to actively retrieve the latest exchange rate data at preset time intervals (such as every minute) and stores the retrieved exchange rate data in a local cache. After completing the above configuration and deployment, a usable real-time exchange rate source module is obtained. For geographical areas requiring multiple currency pairs, configure corresponding exchange rate query submodules separately or support multi-currency queries through the same module; during payment, select and call the corresponding exchange rate source based on the currency required for the current calculation.

[0039] A local transit fund account refers to a fund account opened by a payment application with a partner bank or licensed payment institution in the target geographic region (i.e., the country or region corresponding to the local service model). This account allows for the temporary storage and transfer of local currency funds to merchants for settlement. Each local service model can configure one or more local transit fund accounts, with the account currency being the legal tender or official payment currency of that geographic region (e.g., the Saudi Arabia model corresponds to a Saudi Riyal account; the Hong Kong model can simultaneously configure Hong Kong Dollar and US Dollar accounts). The payment application signs a fund custody or settlement service agreement with a licensed financial institution in the target geographic region and submits qualification materials such as the payment application's business license, payment business license, and anti-money laundering compliance documents. After the financial institution approves the application, it opens a reserve fund account for the payment application, with the account currency determined according to the local legal tender. The payment application injects funds through compliant cross-border remittance channels (such as the Cross-border Interbank Payment System (CIPS) and SWIFT wire transfer). Each local service model can correspond to one or more local transit fund accounts in different currencies.

[0040] Step 4: When the preset payment code display signal is received, the payment code generator is called to generate the user's payment code and output it.

[0041] The payment code display signal refers to the operation instruction that the user actively triggers to display the payment code on the payment application interface. It is pre-set by those skilled in the art and is triggered when the user clicks the pre-set "payment code" button in the application.

[0042] The user payment code refers to a dynamically generated QR code image. This payment code is generated by a payment code generator according to the QR code encoding standard in the local service model. After generation, it is displayed on the user's terminal device screen, and merchants can directly scan it using a POS machine or barcode scanner.

[0043] When a preset payment code display signal is received, it indicates that the user needs to display their payment code to make a payment. Therefore, the payment code generator is called to generate the user payment code and display it on the user's terminal device screen.

[0044] If the preset payment code is not displayed, it means that the user does not need to use the user payment code for payment at this time, and no additional operation is required.

[0045] Step 5: When the scan of the user's payment code is detected, retrieve the merchant's account and collect the local currency amount entered by the merchant. Call the real-time exchange rate source to convert the local currency amount to the corresponding RMB amount, pre-freeze the RMB amount and output a preset payment confirmation signal.

[0046] A merchant account is an internal identification number assigned to a merchant by the payment application. After registering with the payment application, the application generates an internal account for the merchant. This account is associated with the merchant's name, settlement account, and acquiring institution information, including a local currency settlement account (used to receive local currency transferred from a local transit fund account) and a RMB settlement account (used to receive direct RMB payments). Simultaneously, a merchant number (a publicly displayed identifier) ​​corresponding to the internal account is generated. This merchant number is encoded into a merchant QR code, which the merchant can download, print, or display at the checkout. During payment, the corresponding merchant account can be obtained by scanning the merchant QR code or reading the merchant number uploaded by the POS machine. The information for the local currency settlement account and RMB settlement account is entered and bound to the merchant account during registration; the payment application is responsible for verification and storage.

[0047] The local currency amount refers to the amount in the legal tender of the place where the transaction takes place, as used by the merchant when setting the price or by the user when confirming payment. When a user's payment code is scanned, the local currency amount is obtained by the merchant entering and uploading it to the payment application at the POS terminal.

[0048] The RMB amount refers to the price denominated in RMB after converting the merchant's listed price or the user's input local currency amount using the real-time exchange rate. The current exchange rate is obtained by calling a real-time exchange rate source, and the local currency amount is multiplied by the exchange rate to get the RMB amount.

[0049] Pre-freezing refers to a payment application temporarily locking a corresponding amount of RMB funds in a user's account before the user confirms payment. These funds cannot be used for other transactions or actually transferred. Specifically, the payment application freezes the RMB funds in the user's account, generating a freeze record and reducing the available balance. The funds are then deducted from the account after the user confirms payment. If the user does not confirm or cancel within the pre-set waiting time, the freeze is lifted.

[0050] The payment confirmation signal is an instruction that prompts the user to view the actual payment amount and confirm the payment. It is pre-set by those skilled in the art and is triggered after the payment application completes the currency conversion and pre-freezing. It is displayed on the user's mobile terminal device in the form of a confirmation dialog box.

[0051] The method for detecting that a user's payment code has been scanned is as follows: When the payment application generates a payment code, it registers a session to be scanned with the backend server. After the merchant scans the code, it sends the session ID and merchant information to the server. The server confirms that the payment code has been scanned by matching the session ID and obtains the local currency amount entered by the merchant.

[0052] When a scanned user payment code is detected, it indicates that the user's payment code has been scanned by the merchant. At the same time, the merchant's account is retrieved and the local currency amount entered by the merchant is collected. The real-time exchange rate source is used to convert the local currency amount to the corresponding RMB amount. The RMB amount is pre-frozen and a payment confirmation signal is output to the user's mobile terminal screen, waiting for the user to confirm the actual RMB amount to be paid.

[0053] If no scan of the user's payment code is detected, it means that the merchant has not scanned the user's payment code and does not need to perform a payment action.

[0054] Step 6: When the merchant's QR code is detected, retrieve the merchant's account and obtain the amount of local currency to be paid. Use the real-time exchange rate source to convert the local currency amount to the corresponding RMB amount, pre-freeze the RMB amount, and output a preset payment confirmation signal.

[0055] A merchant payment code is a static or dynamic QR code displayed by a merchant that contains payment information. This code includes information such as the merchant account, order number, and amount. The merchant payment code is obtained by a user scanning it with a payment application; the payment application then parses the code to extract the merchant account and order information.

[0056] The local currency amount in this step is obtained by the user through the application interface or by parsing the merchant's QR code when the user actively scans the code to pay.

[0057] When a merchant's QR code is detected, it indicates that the user needs to make a payment. At this time, the merchant's account is retrieved through the QR code, and the amount of local currency to be paid is obtained. The local currency amount is converted to RMB by calling the real-time exchange rate source. The RMB amount is pre-frozen, and a payment confirmation signal is output to the user's mobile terminal screen, waiting for the user to confirm the actual amount of RMB to be paid.

[0058] If the merchant's QR code is not recognized, it means that the user has not yet actively scanned the code to pay and no payment action is required.

[0059] Step 7: When the user confirms the amount, deduct the RMB amount from the preset user account and transfer the local currency amount from the local transfer fund account to the merchant account.

[0060] The amount confirmation signal is a confirmation signal from the user regarding the amount of RMB to be paid. Receiving this signal means that the user has confirmed that payment can proceed. This signal is pre-set by those skilled in the art and is triggered when the user clicks the confirmation button in the confirmation dialog box, sending feedback to the payment application backend.

[0061] A user account refers to a RMB fund account opened by a user in a payment application, which holds the user's principal deposits and records transaction history. After a user completes real-name registration and links their bank card in the payment application, the application generates an internal virtual account for them, with the account balance measured in RMB.

[0062] When a confirmation signal is received from the user regarding the amount, it indicates that the user has confirmed the current amount in RMB and payment can proceed. Therefore, the RMB amount is deducted from the user's account. Before deduction, the account balance is verified. If sufficient, the corresponding amount is transferred from the available balance to the payment application's settlement account, and a deduction record is generated. Then, a transfer instruction is sent to the partner bank or payment institution based on the local currency amount, transferring an equivalent amount in local currency from the local intermediary funds account to the merchant's account. For example, in Saudi Arabia, this can be achieved by connecting to the Mada payment network or the API of a partner bank, sending transfer instructions in standard ISO 8583 messages or JSON format; in Hong Kong, it can be achieved by connecting to the FPS (Fast Payment System). After successful transfer, the payment application records the transaction completion status and pushes a payment success notification and displays the transaction statement in RMB to the user's terminal, while simultaneously sending a settlement completion notification to the merchant's terminal.

[0063] If no confirmation signal is received from the user regarding the amount to be paid, it means that the user has not confirmed the amount of RMB to be paid, has doubts about the amount, or does not need to pay. If the user does not confirm or cancel after the preset waiting time has expired, the pre-freeze will be lifted.

[0064] To ensure the reliability of the payment process, the following fault tolerance mechanisms can be set: support automatic retry (e.g., 3 times) when calling the real-time exchange rate source; notify the user and terminate the transaction after a retry failure; provide advance notice when the user's account balance is insufficient; automatically refund the deducted amount when the transfer fails; and terminate the payment when the merchant account is invalid.

[0065] This also includes a method for verifying user location, which includes: Step 10: Obtain the user's cross-border travel information and parse the user's destination from the cross-border travel information.

[0066] Cross-border travel information refers to information that users book before departure or during their trip that can prove their cross-border travel destination, including but not limited to e-ticket orders, hotel booking records, visa information, and customs entry records. After obtaining user authorization, payment applications collect this information through the following channels: reading flight confirmation emails from the user's inbox, calling the API of third-party travel management applications (such as TravelSky), scanning screenshots of flight or hotel orders uploaded by the user and performing text recognition, and allowing users to manually enter their departure and destination points.

[0067] The user's destination refers to the country or region the user plans to visit, as parsed from cross-border travel information. This is obtained by: extracting the country or region code corresponding to the arrival city from e-ticket orders; extracting the country or region where the hotel is located from hotel booking records; and extracting information manually entered by the user. When destinations from multiple sources are inconsistent, the system determines the destination according to the following priority: e-ticket orders take precedence over hotel booking records, and hotel booking records take precedence over manually entered information. If a unique destination still cannot be determined according to the above rules (e.g., multiple tickets exist with different destinations), a confirmation interface will pop up on the user's terminal, allowing the user to manually select the final destination.

[0068] Step 11: Locate the geographic area where the user's destination falls within the geofencing map.

[0069] The destination geographic region refers to the geographic area matched with the user's destination on the geofencing map. Based on the country or region code of the user's destination, the corresponding geographic region is found in the geofencing map and output as the destination geographic region.

[0070] Step 12: If the destination geographic region is the same as the geographical region, output the geographic region.

[0071] If the destination geographic area is the same as the geographic area, it means that the user's location, determined by the user's mobile terminal device's Global Navigation Satellite System, is correct, and the geographic area where the user's location falls is also the destination geographic area where the user's destination falls. Therefore, the geographic area is correct, and the geographic area is output to the payment application backend.

[0072] Step 13: If the destination geographical region is different from the geographic region, output the destination geographical region as the geographic region.

[0073] If the destination geographical area is different from the geographic area, it means that there is a discrepancy between the user's location located by the Global Navigation Satellite System of the user's mobile terminal device and the user's destination. In cross-border payment scenarios, GPS signals are easily interfered with, while itinerary information (such as air tickets) has higher credibility and intent orientation. Therefore, itinerary information is given priority over GPS positioning as the basis for judging the geographic area. Thus, the geographic area where the user's destination falls is output as the actual geographic area to the payment application backend.

[0074] This also includes: Step 14: Retrieve the merchant's historical transaction records based on the merchant's account.

[0075] Historical transaction records refer to all transaction data completed by a merchant on a payment application. Each historical transaction record includes transaction time, transaction amount, transaction currency, settlement amount, settlement currency, and transaction status. The payment application retrieves the merchant's historical transaction records from the transaction record database, using the merchant's account as an index. The transaction record database stores every transaction record of the merchant, and those skilled in the art can implement it using a relational database (such as MySQL).

[0076] Step 15: Search for recent transaction records from historical transaction records according to the preset time period.

[0077] The time period refers to a fixed time range used to select historical transaction records. For example, 30 days or 90 days, or it can be dynamically adjusted according to the merchant's transaction frequency. The time period is preset by those skilled in the art.

[0078] Recent transaction records refer to transaction flows that fall within a specific time period from historical transaction records. Using the current system time as the cutoff point, the system traces back the number of days in the time period to extract all transaction records whose transaction times fall within that period.

[0079] Step 16: Analyze the trading currencies and the number of transactions corresponding to each currency in recent transaction records.

[0080] Transaction currency refers to the type of currency a merchant has actually received in historical transactions, such as Saudi Riyal, US Dollar, and Chinese Yuan. It is obtained by reading the transaction currency from each recent transaction record.

[0081] The number of transactions refers to the total number of transactions for each currency in recent transaction records, grouped by currency. Recent transaction records are grouped by currency field, and the number of records within each group is counted.

[0082] Step 17: Count the types of currencies traded. If there are more than 1 types of currencies, select the currency with the most transactions and choose it as the preferred currency.

[0083] Currency type refers to the number of different currencies appearing in recent transaction records. The total number of groups is calculated after grouping by currency. For example, if only the Saudi Riyal appears in recent transaction records, the currency type is 1; if both the Saudi Riyal and the US dollar appear, the currency type is 2.

[0084] Preferred currencies refer to currencies that are most likely to be accepted by merchants based on their historical transaction habits.

[0085] If there is more than 1 currency type, it means that the merchant can accept 2 or more currencies. Therefore, you need to select one of the currencies for payment and filter out the currency with the most transactions. The currency with the most transactions is selected as the preferred currency.

[0086] If the number of currency types is no more than 1, it means that the merchant can only accept one type of currency, and payment will be made directly in that currency type.

[0087] Step 18: Find the corresponding reference geographical area based on the preferred currency.

[0088] The reference geographic region refers to the geographic region corresponding to the preferred currency. Those skilled in the art pre-establish a mapping table between currencies and countries (or regions), with each currency associated with only one default geographic region (e.g., "Saudi Riyal: Saudi Arabia", "Euro: Germany"). When the preferred currency has a unique default geographic region in this mapping table, that region is output as the reference geographic region. If a currency does not have a default region configured in the mapping table, or if the user requires more precise region determination (e.g., the same currency corresponds to multiple potential regions), auxiliary rules can be used: query the merchant's registered location or the country of the acquiring institution; if the legal tender of that country matches the preferred currency, it is used as the reference geographic region; if it cannot be obtained or still does not match, a prompt message is output or the switch is abandoned, reverting to the original local service mode. The above auxiliary rules are optional implementation methods, primarily based on the default regions pre-configured by those skilled in the art. If the reference geographic region still cannot be determined according to the above mapping rules and auxiliary rules, the subsequent switching operation is not performed, the current local service mode is maintained, and the transaction is completed according to the basic payment process.

[0089] Step 19: If the reference geographic region and the geographic region are inconsistent, find the corresponding reference service mode in the geographic service database based on the reference geographic region, and update the local service mode to the reference service mode.

[0090] The reference service mode refers to the local service mode corresponding to the reference geographic region in the geographic service database. Using the reference geographic region as an index, the database is queried for its configured payment code generator, real-time exchange rate source, and local intermediary funds account information; the results are then used as the reference service mode.

[0091] If the reference geographic region and the actual geographic region are inconsistent, it indicates that the user's current geographic region differs from the geographic region corresponding to the currency the merchant has historically used in transactions. This could be because the user is located at the border of two countries, and the GPS signal may have drifted to the neighboring country, or the merchant is located at the border but their main customer base comes from another country, leading the merchant to prefer using the neighboring country's currency. In this case, the reliability of GPS positioning is lower than the merchant's historical preference data. Therefore, based on the reference geographic region, the corresponding reference service mode is searched in the geographic service database, and the currently used local service mode is updated to this reference service mode. Subsequently, currency conversion and fund transfer are performed according to the real-time exchange rate source and local transit funds account in the reference service mode. The updated local service mode is valid in the current payment session; subsequent payments will re-execute steps 1 to 3 to redetermine the geographic region and service mode based on the latest location.

[0092] If the reference geographic region and the geographic region are the same, it means that the user's current geographic region is the same as the geographic region corresponding to the currency that the merchant has been using in historical transactions. The local service mode corresponding to the geographic region will be used directly for payment.

[0093] The methods for retrieving a merchant's historical transaction records based on their account include: Step 140: Divide the user's activity range into a preset radius range, with the user's location as the center.

[0094] The radius range refers to the distance value that defines the size of the user's activity area. For example, 500 meters or 1000 meters, which is preset by those skilled in the art and can be dynamically adjusted according to the sparseness of the geofence.

[0095] The user activity range refers to the circular area covered by the user's location as the center and the radius of that area.

[0096] Step 141: Locate the geographic areas where the user's activity range intersects in the geofence map.

[0097] The geographical regions that intersect with the user's activity range refer to the set of geographical regions that intersect with geographical regions in the geofence map. Geometric intersection calculations are performed between the user's activity range (circle) and each geographical region (polygonal region) in the geofence map. If the intersection of two regions is not empty, then that geographical region is recorded as an intersecting geographical region.

[0098] Step 142: Count the number of geographical areas where user activity ranges intersect.

[0099] The number of regions refers to the total number of geographical areas that intersect with the user's activity range. The number of regions is calculated by counting all geographical areas that meet the intersection criteria.

[0100] Step 143: If the number of regions is greater than 1, retrieve the merchant's historical transaction records based on the merchant account.

[0101] If the number of regions is greater than 1, it means that the user's activity range intersects with two or more regions. The user may be located near national or regional borders, and the GPS positioning may be ambiguous. In this case, it is necessary to retrieve the merchant's historical transaction records to help determine the user's true location.

[0102] If the number of regions is not greater than 1, that is, the number of regions is equal to 1, it means that the user's activity range only intersects with one geographical region and the user is far from the boundary. In this case, the execution steps refer to steps 1435 to 1439.

[0103] Reference Figure 2 If the number of regions is greater than 1, the methods for retrieving a merchant's historical transaction records based on the merchant account include: Step 1430: Define the geographical areas where user activity ranges intersect as the areas to be determined.

[0104] Step 1431: Search for the legal tender corresponding to the region to be determined in the preset regional currency database.

[0105] Regional currency databases contain mappings between geographical regions and their corresponding legal tender. Those skilled in the art, based on official currency information for various countries or regions, use the country code of the geographical region as the key and the ISO 4217 code of the region's legal tender as the value to compile a mapping table and store it in the database, thus forming a regional currency database. For geographical regions with multiple legal tenders (such as the Hong Kong Special Administrative Region of China), multiple currency codes are stored in a list format.

[0106] Legal tender refers to the official currency of a country or region as stipulated by law. It is indexed by geographical region and can be retrieved from a regional currency database. For example, the legal tender of Saudi Arabia is the Saudi Riyal (SAR), and the legal tender of the United States is the US Dollar (USD).

[0107] Step 1432: Count the legal types of legal tender.

[0108] The legal tender category refers to the number of different types of legal tender corresponding to each geographical region in the region to be judged. The process involves iterating through each geographical region in the region to be judged, retrieving its legal tender from the regional currency database, placing these legal tenders into a set, removing duplicates, and counting the number of legal tenders in the set, which represents the legal tender category.

[0109] Step 1433: If the number of legal categories is no more than 1, the local service mode is used directly and the geographical area corresponding to the area to be determined is regarded as the same geographical area.

[0110] If the number of legal tender types is no more than 1, it means that although the multiple geographical areas covered by the user's activity range are divided into different regions in the geofencing map, these regions use the same legal tender. In this case, these regions are no longer distinguished, but are treated as a whole, that is, the currently selected local service mode is used directly, and there is no need to further retrieve the merchant's historical transaction records.

[0111] Step 1434: If the number of legal categories is greater than 1, retrieve the merchant's historical transaction records based on the merchant account.

[0112] If there is more than 1 legal currency, it means that the user's activity range covers multiple geographical areas involving multiple legal currencies. Therefore, it is still necessary to select the payment currency according to the merchant's payment habits and retrieve the merchant's historical transaction records based on the merchant's account.

[0113] This also includes a method for selecting the preferred currency for trading, which includes: Step 170: If RMB is not among the transaction currencies, then select the transaction currency with the most transactions and use it as the preferred currency, and continue to steps 18 to 19.

[0114] If RMB is not among the transaction currencies, it means that the merchant has no transactions settled in RMB. Therefore, we count the number of times other transaction currencies have appeared in the merchant's history, select the currency with the most transactions as the preferred currency, and find a reference geographical area based on this currency, and switch the local service mode if necessary.

[0115] Step 171: If RMB is present in the transaction currency and the number of transactions exceeds the preset threshold, it is determined that the merchant accepts RMB payment, and RMB is selected as the preferred currency to replace the transaction currency with the most transactions.

[0116] The frequency threshold is used to determine whether a merchant's transaction frequency in accepting RMB reaches the integer limit for enabling direct RMB payments. It is used to exclude merchants who occasionally accept RMB transactions. The frequency threshold is preset by those skilled in the art and can be adjusted according to risk control strategies.

[0117] If RMB is present in the transaction currency and the number of transactions exceeds the preset threshold, it indicates that the merchant can reliably receive RMB payments, and RMB will be selected as the preferred currency to replace the most frequently used transaction currency.

[0118] Step 172: Use the real-time exchange rate source to convert the local currency amount entered by the merchant or the local currency amount to be paid into RMB.

[0119] Step 173: Pre-freeze the RMB amount and output a payment confirmation signal.

[0120] Step 174: When the user confirms the amount, deduct the RMB amount from the user's account and directly pay it to the RMB settlement account associated with the merchant's account.

[0121] A RMB settlement account refers to a bank account that a merchant can use to receive direct RMB payments. Merchants bind this account when registering with a payment application. The currency of this account is RMB, and the account holder is the merchant (or the payee designated by the merchant). Account information includes the name of the opening bank, account number, and account holder name. After registering on the payment platform, the merchant enters their RMB settlement account information. The payment platform verifies this information (such as small-amount payment verification or online verification with the bank). Once verification is successful, the account is associated with and stored in the merchant's account.

[0122] When the payment application receives a confirmation signal from the user regarding the amount to be paid, it means that the user has confirmed the amount of RMB to be paid and agreed to the payment. The RMB amount deducted from the user's account by the payment application will be directly settled to the RMB settlement account designated by the merchant through RMB cross-border payment channels (such as CIPS or interbank transfer).

[0123] In this method, when RMB is present in the transaction currency and the number of transactions meets the threshold, RMB is directly selected as the preferred currency and the RMB direct payment process is initiated. The steps of searching for a reference geographical area based on the preferred currency and switching the service mode are no longer performed. Only when RMB is not present is the search for a reference area based on the currency with the most transactions and the mode switching performed.

[0124] Reference Figure 3 It also includes a method for handling cases where the number of regions is equal to 1, which includes: Step 1435: Search for the local official currency of the geographical region in the preset regional currency database and count the official types corresponding to the local official currency.

[0125] Local official currency refers to the legally recognized currency in circulation under the laws of a country or region. Using a geographical region identifier as an index, the corresponding legal tender for that region is searched in a regional currency database. If a geographical region has multiple legal tenderes (e.g., the Hong Kong Special Administrative Region lists both the Hong Kong dollar and the US dollar as official payment currencies), then all of these currencies are considered official currencies of that region.

[0126] Official types refer to the number of different official currencies in a geographical region, which is obtained by counting the number of local official currencies.

[0127] Step 1436: If the number of official types is greater than 1, then proceed to steps 14 to 17 to obtain the preferred currency based on the merchant's habits and preferences.

[0128] If the number of official types is greater than 1, it indicates that there are multiple legal tenders in this geographical area, so proceed to steps 14 to 17.

[0129] If the number of official currencies is no more than 1, it means that there is only one legal tender in the geographical area, and all payments should be made directly in this legal tender.

[0130] Step 1437: If the preferred currency falls into the local official currency, the preferred currency will be used as the default payment currency for the merchant account, and the default payment amount corresponding to the default payment currency will be calculated based on the merchant exchange rate provided by the merchant account.

[0131] The default payment currency refers to the merchant's default settlement currency selected based on the merchant's historical transaction habits when a user makes a payment within a single geographical area.

[0132] The merchant exchange rate refers to the conversion ratio used to convert a merchant's listed local currency amount into another currency amount. Merchant exchange rates are set by the merchant themselves. During merchant registration or subsequent maintenance, the merchant enters the exchange rates between the currencies they accept through the back-end management system; or, when a payment transaction occurs, the merchant exchange rate is obtained in real time from the merchant's POS terminal or QR code. Merchant exchange rates may differ from real-time market exchange rates; for example, merchants may set preferential exchange rates or charge additional fees for RMB transactions. Merchant exchange rates can be provided in either forward (e.g., 1 HKD equals 0.128 USD) or reverse (e.g., 1 USD equals 7.8 HKD), and the system can automatically identify the direction and convert accordingly. If the direction is unclear, a preset agreement can be made (e.g., merchants are uniformly required to provide the exchange rate as "Local Currency: Default Currency").

[0133] The difference between merchant exchange rates and real-time exchange rates: Merchant exchange rates are set by the merchant and are used to convert local currency amounts to the default payment currency (e.g., HKD to USD), reflecting the merchant's actual settlement preferences. Real-time exchange rates are obtained by the payment application through a third-party data service and are used to convert the default payment amount to RMB amounts visible to the user. When a merchant enters a merchant exchange rate, the payment application obtains the market exchange rate and calculates the deviation. If the deviation exceeds a preset deviation threshold (e.g., 5%), the merchant is prompted to confirm or re-enter the exchange rate. The confirmed exchange rate is marked as "confirmed" and can be used directly for subsequent payments.

[0134] The default payment amount refers to the amount after converting the merchant's listed price in local currency to the default payment currency using the merchant's exchange rate. This is calculated by multiplying the merchant's listed price in local currency by the exchange rate provided by the merchant (if the local currency and the default payment currency are the same, the amount remains unchanged).

[0135] If the preferred currency falls into the local official currency set, it means that the preferred currency belongs to the local official currency set. The preferred currency will be used as the merchant's default payment currency, and the default payment amount corresponding to the default payment currency will be calculated according to the merchant's exchange rate.

[0136] Step 1438: Call the real-time exchange rate source to convert the default payment amount into the corresponding RMB amount, pre-freeze the RMB amount, and output a payment confirmation signal.

[0137] The RMB amount in this step is obtained by converting the default payment amount using a real-time exchange rate source.

[0138] Step 1439: When the user confirms the amount, deduct the RMB amount from the user's account and transfer the default payment amount from the local transit funds account corresponding to the default payment currency to the merchant's account.

[0139] When a confirmation signal is received from the user, it indicates that the user has confirmed the amount to be paid in RMB and agrees to the payment. Therefore, the RMB amount is deducted from the user's account. Then, using the current local service mode and default payment currency as an index, the system matches the corresponding local intermediary funds account. If a match is found, the default payment amount is transferred from that account to the merchant's account. If no matching account is found, the system returns to the default account corresponding to the local legal tender, converts the default payment amount to the local legal tender amount at the real-time exchange rate, and then transfers it to the merchant's account or displays an error message.

[0140] This also includes a method for handling situations where the preferred currency falls into the local official currency and the local official currency includes the Renminbi. This method includes: Step 14370: If the preferred currency is not RMB, proceed to steps 1435 to 1439.

[0141] If the preferred currency is not RMB, it means that the currency with the most transactions according to the merchant's historical transaction records is not RMB. The payment will be completed through the local transit fund account using the default payment currency.

[0142] Step 14371: If the preferred currency is RMB, convert the local currency amount into the RMB amount corresponding to the preferred currency based on the merchant exchange rate provided by the merchant account, pre-freeze the RMB amount, and output a payment confirmation signal.

[0143] If the preferred currency is RMB, it means that the currency with the most transactions according to the merchant's historical transaction records is RMB, which is the currency most frequently used in the merchant's daily settlement. It is determined that the merchant stably accepts RMB payments. Therefore, the local currency amount is converted into the RMB amount corresponding to the preferred currency according to the merchant's exchange rate, the RMB amount is pre-frozen, and a payment confirmation signal is output to the user's mobile terminal for display.

[0144] Step 14372: When the user confirms the amount, deduct the RMB amount from the user's account and pay it directly to the RMB settlement account associated with the merchant's account.

[0145] When a confirmation signal is received from the user, it means that the user has confirmed the payment amount and agreed to the payment. The RMB will be deducted from the user's account and directly paid to the merchant's RMB settlement account, skipping the step of transferring local currency from the local transit fund account.

[0146] The methods for obtaining the amount to be paid in local currency include: Step 60: When the signal to capture the amount sent by the user is received, control the camera to start capturing the image of the merchant's price tag.

[0147] The amount capture signal refers to the user's active triggering of an operation command that requires the camera to capture an image of the merchant's price tag. This signal is pre-set by those skilled in the art; for example, it can be presented as a "photo recognition" button next to the interface where the user manually enters the amount, and the amount capture signal is triggered when the user clicks the button.

[0148] The camera refers to the built-in camera on the user's mobile device. The payment application calls the camera access interface provided by the mobile device's operating system (such as CameraX on Android or AVFoundation on iOS), and after obtaining user authorization, opens the rear camera for real-time preview and image capture.

[0149] A merchant price tag image refers to an image captured by a user that contains the merchant's price information. The image should include price data, currency symbols, or units. The user points the camera at the product price tag or price list, clicks the capture button, and the camera captures a frame and saves it as an image file, or directly captures the current frame from the preview stream.

[0150] Step 61: Perform character recognition on the merchant's price tag image and extract the numerical information as the initial currency amount.

[0151] Numerical information refers to the numerical portion extracted from the character recognition of merchant price tags. Payment applications utilize the mobile terminal's built-in OCR engine (such as Huawei HMS Core) or connect to cloud-based OCR services (such as Baidu OCR or Tencent OCR). Taking the merchant price tag image as input, the engine recognizes the numbers and currency symbols in the image, outputting the recognition result text. Regular expression matching is then used to extract strings conforming to numerical formats (e.g., "99.9" or "150"), which constitutes the numerical information. When OCR recognition fails or the result is unclear, the user is prompted to manually input the information or retake the photo.

[0152] The initial currency amount refers to the initial currency amount extracted from the character recognition of the merchant's price tag image. Because character recognition may have errors, this amount needs to be verified by the user before it can be used for payment. The extracted numerical information is converted into a numeric type and displayed as the initial currency amount in the amount input box on the user's mobile device for the user to view.

[0153] Step 62: Output the initial currency amount and the preset numerical confirmation signal.

[0154] A numerical confirmation signal is a prompt that asks the user whether they confirm the initial currency amount, and is preset by someone skilled in the art. Specifically, it can be triggered after the initial currency amount is received, causing the payment application to display a dialog box on the interface showing "Identify Amount, Correct?" and providing "Correct" and "Modify" buttons.

[0155] Step 63: When a signal indicating that the value is correct is received from the user, the initial currency amount is output as the local currency amount.

[0156] The numerical accuracy signal is a feedback signal indicating that the user has confirmed the initial currency amount is correct. It is preset by someone skilled in the art. It is triggered when the user clicks the "Correct" button after verifying that the amount is correct.

[0157] When a signal indicating that the value is correct is received from the user, it means that the amount displayed on the user verification interface is consistent with the actual price. Therefore, the initial currency amount is output to the payment application backend as the local currency amount.

[0158] If no user feedback is received indicating that the value is correct, it means that the initial currency amount received by the user does not match the actual amount. The user can choose to manually modify the amount and then confirm. In this case, the output local currency amount will be the value modified by the user.

[0159] Based on the same inventive concept, embodiments of the present invention provide a cross-border RMB payment system based on geofencing and currency conversion.

[0160] A cross-border RMB payment system based on geofencing and currency conversion includes: The acquisition module is used to obtain user location, local currency amount, and cross-border travel information; The memory stores computer programs that can be loaded by a processor and executed for cross-border RMB payment methods based on geofencing and currency conversion. The processor loads and executes programs from memory.

[0161] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional modules is used as an example. In practical applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the system, device, and unit described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0162] The above description is merely a preferred embodiment of the present invention. The scope of protection of the present invention is not limited to the above embodiments. All technical solutions falling within the scope of the present invention's concept are within the scope of protection of the present invention. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of the present invention should also be considered within the scope of protection of the present invention.

Claims

1. A cross-border RMB payment method based on geofencing and currency conversion, characterized in that, include: Step 1: Obtain user location; Step 2: Locate the geographic area where the user's location falls within the preset geofencing map; Step 3: Based on the geographical region, find the corresponding local service mode in the preset geographical service database. The local service mode includes payment code generator, real-time exchange rate source and local intermediary fund account. Step 4: When the preset payment code display signal is received, the payment code generator is invoked to generate and output the user's payment code; Step 5: When the scan of the user's payment code is detected, retrieve the merchant's account and collect the local currency amount entered by the merchant. Call the real-time exchange rate source to convert the local currency amount to the corresponding RMB amount, pre-freeze the RMB amount and output the preset payment confirmation signal. Step 6: When the merchant's QR code is detected, retrieve the merchant's account and obtain the amount of local currency to be paid. Use the real-time exchange rate source to convert the local currency amount to the corresponding RMB amount. Pre-freeze the RMB amount and output a preset payment confirmation signal. Step 7: When the user confirms the amount, deduct the RMB amount from the preset user account and transfer the local currency amount from the local transfer fund account to the merchant account.

2. The cross-border RMB payment method based on geofencing and currency conversion according to claim 1, characterized in that, It also includes a method for verifying user location, which includes: Step 10: Obtain the user's cross-border travel information and parse the user's destination from the cross-border travel information; Step 11: Locate the geographic area where the user's destination falls within the geofencing map; Step 12: If the destination geographic region is the same as the geographical region, output the geographic region; Step 13: If the destination geographical region is different from the geographic region, output the destination geographical region as the geographic region.

3. The cross-border RMB payment method based on geofencing and currency conversion according to claim 2, characterized in that, Also includes: Step 14: Retrieve the merchant's historical transaction records based on the merchant account; Step 15: Search for recent transaction records from historical transaction records according to the preset time period; Step 16: Analyze the trading currencies and the number of transactions corresponding to each currency in recent transaction records; Step 17: Count the types of currencies traded. If there are more than 1 types of currencies, select the currency with the most transactions and use it as the preferred currency. Step 18: Find the corresponding reference geographical area based on the preferred currency; Step 19: If the reference geographic region and the geographic region are inconsistent, find the corresponding reference service mode in the geographic service database based on the reference geographic region, and update the local service mode to the reference service mode.

4. The cross-border RMB payment method based on geofencing and currency conversion according to claim 3, characterized in that, Methods for retrieving a merchant's historical transaction records based on their account include: Step 140: Divide the user's activity range into a preset radius range, with the user's location as the center; Step 141: Locate the geographical areas where the user's activity range intersects in the geofence map; Step 142: Count the number of geographical areas where user activity ranges intersect; Step 143: If the number of regions is greater than 1, retrieve the merchant's historical transaction records based on the merchant account.

5. The cross-border RMB payment method based on geofencing and currency conversion according to claim 4, characterized in that, If the number of regions is greater than 1, the methods for retrieving a merchant's historical transaction records based on the merchant account include: Step 1430: Define the geographical area where the user activity ranges intersect as the area to be determined; Step 1431: Search for the legal tender corresponding to the region to be determined in the preset regional currency database; Step 1432: Count the legal types of fiat currency; Step 1433: If the number of legal categories is no more than 1, the local service mode is used directly and the geographical area corresponding to the area to be determined is regarded as the same geographical area; Step 1434: If the number of legal categories is greater than 1, retrieve the merchant's historical transaction records based on the merchant account.

6. The cross-border RMB payment method based on geofencing and currency conversion according to claim 3, characterized in that, It also includes a method for selecting the preferred currency for trading, which includes: Step 170: If RMB is not among the transaction currencies, then select the transaction currency with the most transactions and use it as the preferred currency, and continue to execute steps 18 to 19. Step 171: If RMB is present in the transaction currency and the number of transactions exceeds the preset threshold, it is determined that the merchant accepts RMB payment, and RMB is used as the preferred currency to replace the transaction currency with the most transactions. Step 172: Use the real-time exchange rate source to convert the local currency amount entered by the merchant or the local currency amount to be paid into RMB. Step 173: Pre-freeze the RMB amount and output a payment confirmation signal; Step 174: When the user confirms the amount, deduct the RMB amount from the user's account and directly pay it to the RMB settlement account associated with the merchant's account.

7. The cross-border RMB payment method based on geofencing and currency conversion according to claim 4, characterized in that, It also includes a method for handling cases where the number of regions is equal to 1, which includes: Step 1435: Search for the local official currency of the geographical region in the preset regional currency database and count the official types corresponding to the local official currency; Step 1436: If the number of official types is greater than 1, proceed to steps 14 to 17 to obtain the preferred currency; Step 1437: If the preferred currency falls into the local official currency, the preferred currency will be used as the default payment currency for the merchant account, and the default payment amount corresponding to the default payment currency will be calculated based on the merchant exchange rate provided by the merchant account. Step 1438: Call the real-time exchange rate source to convert the default payment amount into the corresponding RMB amount, pre-freeze the RMB amount and output a payment confirmation signal; Step 1439: When the user confirms the amount, deduct the RMB amount from the user's account and transfer the default payment amount from the local transit funds account corresponding to the default payment currency to the merchant's account.

8. The cross-border RMB payment method based on geofencing and currency conversion according to claim 7, characterized in that, It also includes a method for handling situations where the preferred currency falls into the local official currency and the local official currency includes the Renminbi, the method of which includes: Step 14370: If the preferred currency is not RMB, proceed to steps 1435 to 1439; Step 14371: If the preferred currency is RMB, convert the local currency amount into the RMB amount corresponding to the preferred currency based on the merchant exchange rate provided by the merchant account, pre-freeze the RMB amount, and output a payment confirmation signal. Step 14372: When the user confirms the amount, deduct the RMB amount from the user's account and pay it directly to the RMB settlement account associated with the merchant's account.

9. The cross-border RMB payment method based on geofencing and currency conversion according to claim 1, characterized in that, Methods for obtaining the amount to be paid in local currency include: Step 60: When the signal to capture the amount sent by the user is received, control the camera to start capturing the image of the merchant's price tag; Step 61: Perform character recognition on the merchant's price tag image and extract the numerical information as the initial currency amount; Step 62: Output the initial currency amount and the preset numerical confirmation signal; Step 63: When a signal indicating that the value is correct is received from the user, the initial currency amount is output as the local currency amount.

10. A cross-border RMB payment system based on geofencing and currency conversion, characterized in that: include: The acquisition module is used to obtain user location, local currency amount, and cross-border travel information; A memory for storing the program of the cross-border RMB payment method based on geofencing and currency conversion as described in any one of claims 1 to 9; The processor loads and executes programs from memory.

Images