CN112561507A - Payment access method, electronic device and computer readable storage medium - Google Patents
Payment access method, electronic device and computer readable storage medium Download PDFInfo
- Publication number
- CN112561507A CN112561507A CN202011542635.6A CN202011542635A CN112561507A CN 112561507 A CN112561507 A CN 112561507A CN 202011542635 A CN202011542635 A CN 202011542635A CN 112561507 A CN112561507 A CN 112561507A
- Authority
- CN
- China
- Prior art keywords
- payment
- product
- target
- package
- payment product
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
- G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
- G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/20—Point-of-sale [POS] network systems
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Cash Registers Or Receiving Machines (AREA)
Abstract
The invention discloses a payment access method, an electronic device and a computer readable storage medium, wherein the method comprises the following steps: acquiring a payment product used by a merchant object as a target payment product; determining a system interface used by the target payment product; matching a payment product package for the target payment product, wherein the payment product package is obtained by abstracting a plurality of product scenes according to service scenes, associating a system interface for each product scene and packaging; and accessing the merchant object into the matched payment product package. By the scheme, the technical problem of resource waste caused by the fact that an access mode needs to be specially designed for each merchant in the prior art is solved, and the technical effect of simply and efficiently accessing the merchants to the payment system is achieved.
Description
Technical Field
The invention relates to the technical field of internet, in particular to a payment access method, an electronic device and a computer readable storage medium.
Background
The current acquiring system generally supports a plurality of acquiring modes and provides transaction modes such as card swiping consumption, staging, Unionpay, Payment treasure, WeChat code scanning, face payment and the like. However, in the existing billing system, since the card center billing service is supported first, the pos machine adopts 8583 message format and H5 page interface, and then, the support for the billing service of head office retail is increased, and the json message format is increased for the pos machine. Due to the support of the diversity of the collection modes, multiple sets of interface documents need to be maintained, for merchants, different front-end interfaces need to be developed according to different service scenes during docking, and different programs need to be developed for docking by a background system.
This results in independent payment collection methods, no resource sharing, and thus resource waste and complicated merchant access.
In view of the above problems, no effective solution has been proposed.
Disclosure of Invention
The invention aims to provide a payment access method, an electronic device and a computer readable storage medium, and further solves the technical problems of resource waste and complex access operation in the existing payment field.
The invention solves the technical problems through the following technical scheme:
according to an aspect of the present invention, there is provided a payment access method, including the steps of:
acquiring a payment product used by a merchant object as a target payment product;
determining a system interface used by the target payment product;
matching a payment product package for the target payment product, wherein the payment product package is obtained by abstracting a plurality of product scenes according to service scenes, associating a system interface for each product scene and packaging;
and accessing the merchant object into the matched payment product package.
In one embodiment, determining a system interface for use by the targeted payment product comprises:
acquiring product information of the target payment product;
extracting hardware information data from the product information;
and determining the type of a system interface used by the target product according to the hardware information data.
In one embodiment, matching a payment product package for the target payment product comprises:
acquiring identification information of a system interface used by the target product;
calling a plurality of preset payment product packages;
identifying a payment product package associated with the identification information from the plurality of payment product packages;
and using the identified payment product package as the payment product package matched with the target product.
In one embodiment, after accessing the merchant object to the matched payment product package, the method further comprises:
receiving a payment request of a user;
and responding to the payment request, and calling a payment channel to deduct money from the payment request through a payment product package accessed by the merchant object.
In one embodiment, prior to matching a payment product package for the target payment product, comprising:
acquiring different bill receiving service scenes;
classifying the bill receiving service scene according to the type of the collected products in the bill receiving service scene;
determining the type of a front-end interface corresponding to each type of order receiving service scene;
and packaging to obtain a plurality of product packages according to each type of order receiving service scene and the type of the corresponding front-end interface, wherein the plurality of product packages are accessed by different merchants according to the type of the used payment products.
In one embodiment, after accessing the merchant object to the matched payment product package, the method further comprises:
receiving a payment request;
determining, in response to the payment request, a payment system with which the payment request is associated;
calling a preset shared payment channel to be associated to the payment system;
and completing the deduction service through the payment system.
According to another aspect of the invention, there is provided an electronic device comprising a memory and a processor, the memory for storing a payment access system executable by the processor, the payment access system comprising:
the acquisition module is used for acquiring the payment product used by the merchant object as a target payment product;
a determination module for determining a system interface used by the target payment product;
the matching module is used for matching a payment product package for the target payment product, wherein the payment product package is obtained by abstracting a plurality of product scenes according to service scenes and associating system interfaces for the product scenes, and is obtained by packaging;
and the access module is used for accessing the merchant object into the matched payment product package.
In one embodiment, the determining module comprises:
a first acquisition unit, configured to acquire product information of the target payment product;
an extraction unit for extracting hardware information data from the product information;
and the determining unit is used for determining the type of the system interface used by the target product according to the hardware information data.
In one embodiment, the matching module comprises:
a second obtaining unit, configured to obtain identification information of a system interface used by the target product;
the calling unit is used for calling a plurality of preset payment product packages;
an identification unit configured to identify a payment product package associated with the identification information from the plurality of payment product packages;
and the generating unit is used for taking the identified payment product package as the payment product package matched with the target product.
In one embodiment, the electronic device further includes:
the receiving module is used for receiving a payment request of a user after the merchant object is accessed into the matched payment product package;
and the calling module is used for responding to the payment request, calling a payment channel to deduct money from the payment request through a payment product package accessed by the merchant object.
According to yet another aspect of the present invention, there is provided a computer apparatus comprising: a memory, a processor and a computer program stored on the memory and executable on the processor, the processor implementing the steps of the above method when executing the computer program.
According to yet another aspect of the invention, a non-transitory computer-readable storage medium is provided, having stored thereon a computer program which, when executed by a processor, implements the steps of the above-described method.
The positive progress effects of the invention are as follows: the method and the device have the advantages that a plurality of product scenes are obtained according to abstraction of service scenes, the system interfaces are associated with the product scenes, a plurality of payment product packages are obtained through encapsulation, when merchants have access requirements, the corresponding payment product packages are matched according to the payment products and the system interfaces used by the merchants, and the merchants are accessed into the payment system.
Drawings
Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The drawings are only for purposes of illustrating the preferred embodiments and are not to be construed as limiting the invention. Also, like reference numerals are used to refer to like parts throughout the drawings. In the drawings:
FIG. 1 is a method flow diagram of a payment access method according to an embodiment of the invention;
FIG. 2 is an architecture diagram of a receive core according to an embodiment of the present invention;
FIG. 3 is a schematic diagram of a payment channel according to an embodiment of the present invention;
FIG. 4 is a block diagram of a payment access arrangement according to an embodiment of the present invention;
fig. 5 is an architecture diagram of an electronic device according to an embodiment of the invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
Considering the diversity of the existing collection supporting modes, multiple sets of interface documents need to be maintained, for merchants, different front-end interfaces need to be developed according to different service scenes during docking, and different programs need to be developed for docking by a background system.
Based on this, in this example, it is considered that a plurality of product scenes can be obtained according to abstraction of the service scene, and a system interface is associated with each product scene, so that a plurality of payment product packages are obtained by encapsulation, and when a merchant accesses, only the appropriate payment product package needs to be matched for access.
Therefore, in this example, a payment access method and an electronic device are provided, and the following specific description is provided for the method and the electronic device:
example one
The method provided by the invention is explained below with reference to the accompanying drawings.
Fig. 1 is a schematic flow chart of an alternative payment access method of the present invention, and as shown in fig. 1, the method may include the following steps S01-S05:
step S01: acquiring a payment product used by a merchant object as a target payment product;
step S02: determining a system interface used by the target payment product;
step S03: matching a payment product package for the target payment product, wherein the payment product package is obtained by abstracting a plurality of product scenes according to service scenes, associating a system interface for each product scene and packaging;
step S04: and accessing the merchant object into the matched payment product package.
In the above embodiment, a plurality of product scenes are obtained by abstracting the service scenes, and the system interface is associated with each product scene, so that a plurality of payment product packages are obtained by encapsulation, and when a merchant has an access demand, the corresponding payment product package is matched according to the payment product and the system interface used by the merchant, so that the merchant is accessed into the payment system.
The system interface described above may include, but is not limited to, at least one of: API interface, h5 interface, sdk interface. That is, refine the integration to the front-end interface, unify the integration and do: API interface, h5 interface, sdk interface. Further, if the target payment product is a POS machine, the associated system interface may be set as a json message interface in the API interface, that is, the 8583 interface at the POS end is cancelled, and the json message interface is uniformly used, which is more favorable for centralized allocation and management.
For the background payment channel, integration can also be performed to realize sharing of the payment channel, and specifically, after the merchant object is accessed into the matched payment product package, a payment request of a user can be received; and responding to the payment request, and calling a payment channel to deduct money from the payment request through a payment product package accessed by the merchant object. Wherein, the payment channel is a pre-integrated payment channel shared by each payment product package.
Specifically, in step S02, the determining a system interface used by the target payment product may include: acquiring product information of the target payment product; extracting hardware information data from the product information; and determining the type of a system interface used by the target product according to the hardware information data.
That is, the product information of the target product can be extracted because the hardware information is recorded therein, and the system interface used by the product can be determined based on the hardware information, so that the type of the system interface of the payment product, that is, which interface is the API interface, the h5 interface, or the sdk interface, can be determined.
When actually implemented, matching a payment product package for the target payment product may include: acquiring identification information of a system interface used by the target product; calling a plurality of preset payment product packages; identifying a payment product package associated with the identification information from the plurality of payment product packages; and using the identified payment product package as the payment product package matched with the target product. That is, a plurality of payment product packages may be generated in advance and then stored, and when a payment product package needs to be matched, the pre-generated product packages may be called out and then matched with the confirmed system interface, and the adapted product package is used as the matched payment product package.
For the payment product package, different order receiving service scenes can be obtained before the payment product package is matched with the target payment product; classifying the bill receiving service scene according to the type of the collected products in the bill receiving service scene; determining the type of a front-end interface corresponding to each type of order receiving service scene; and packaging to obtain a plurality of product packages according to each type of order receiving service scene and the type of the corresponding front-end interface, wherein the plurality of product packages are accessed by different merchants according to the type of the used payment products.
For example: abstracting the service scene into different collection product scenes: POS machine, sweep a yard box, sweep face equipment, public number, APP etc.. That is, the concept of the merchant is ignored, and the money collection products are classified according to the devices used for money collection. Refine the integration to the front end interface, unify the integration and do: API interface, h5 interface, sdk interface. That is, the integration can be performed according to the interface required by the device used for collection. Then, packaging is performed, thereby obtaining a plurality of product packages.
After accessing the merchant object to the matching payment package, a payment request may be received; determining, in response to the payment request, a payment system with which the payment request is associated; calling a preset shared payment channel to be associated to the payment system; and completing the deduction service through the payment system. That is, channels can be shared, thereby realizing full channel support for fast service access.
The specific example is used for explaining, considering that the existing collection modes are various, each collection mode independently maintains one set of interface document, for merchants, different front-end interfaces need to be developed according to different business scenes, and different programs need to be developed for docking of a background system, so that resource waste is caused.
Therefore, in the embodiment, different service scenes and different transaction flows are summarized and shared, the front-end interfaces are unified, and the rear-end interfaces are integrated to realize channel sharing, so that computer resources are saved, and the development of services is promoted.
The interface is commercialized, and specifically, the interface may include:
1) according to different scenes of the order receiving service, abstracting the service scene into different product scenes, for example: abstracting the service scene into different collection product scenes: POS machine, sweep a yard box, sweep face equipment, public number, APP etc.. That is, the concept of the merchant is ignored, and the money collection products are classified according to the devices used for money collection.
2) Refine the integration to the front end interface, unify the integration and do: API interface, h5 interface, sdk interface. That is, integration can be performed according to interfaces required by devices used for collecting money, if the devices are, for example, a pay pal, WeChat, and the like, an h5 interface is uniformly adopted, if the devices are for Unionpay APP payment, an API interface is adopted, and if the devices are for application jump, an sdk interface is adopted. I.e. one integration is performed for the front-end interface. If the POS machine is the POS machine, json message interfaces are uniformly adopted.
Specifically, when the API interfaces are integrated, in order to make the POS interface uniform, the 8583 interface of the POS terminal is abandoned, a json message interface is uniformly used, and for different banking institutions, the POS interfaces are kept consistent, that is, the json message interface is uniformly used for the POS interfaces.
3) From the business perspective, according to the interface of the system and the product scene, a plurality of product packages can be obtained through encapsulation for the selection of the merchant, and the merchant can select a proper product package to access according to the attribute of the merchant. And selecting different product packages for access according to the attributes of the merchants.
Further, in order to provide a secure and stable payment environment and a solution for diversified scenarios, so as to uniformly perform reconciliation and clearing, as shown in fig. 2, a variety of core systems may be built at the acquiring core, for example: the system comprises an offline payment platform, an online payment platform, a payment auxiliary platform and a batch processing platform, and provides a general capability platform; and calling different core systems by the external product according to the universal open interface.
For the payment channel, sharing may be performed, that is, a channel sharing scenario and full channel support are performed, so as to facilitate fast service access, as shown in fig. 3:
1) the acquiring system may access systems within the row, which are called by the acquiring core system, for example: a +, D +, scoring system, card system, etc.
2) The bank union, the bank union two-dimensional code, the bank union face routing gateway, the bank union WeChat, the bank union pay treasured and the like which can be accessed outside the bill collection.
3) Order picking accessible connectivity, visa, masterda, jcb, dahlia, etc.
After the framework is remodeled, the acquiring system can rapidly carry out service access and service expansion, and the problems of repeated development of system functions and non-shared functions can be solved. After the collection system is modified, various product packages can be abstracted by the collection system for service selection, diversified solutions can be provided for services, an interface of a background of the collection system is set to be a universal interface, different scene cores of the collection core are called according to different service scenes, the collection scene cores can call payment channels, and due to the sharing of the payment channels, the payment channels can be called by the different scene cores without frequent maintenance after the channels are developed once.
In the above example, the integration is performed according to the product scenario, and the integration and encapsulation are performed on the interface, so that a plurality of product packages are formed, and when a merchant accesses the product packages, the merchant only needs to select the product packages required by the merchant. Furthermore, the acquiring system shares the payment channel, can quickly iterate business requirements of both parties, and shares development resources.
Through the above description of the embodiments, those skilled in the art will clearly understand that the method of the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but in many cases, the former is a better implementation manner.
Example two
Based on the payment access method provided in the first embodiment, a payment access system is provided in this embodiment, and specifically, fig. 4 shows an optional structural block diagram of the payment access system, where the payment access system is divided into one or more program modules, and the one or more program modules are stored in a storage medium and executed by one or more processors, so as to complete the present invention. The program modules referred to in the present invention refer to a series of computer program instruction segments capable of performing specific functions, and are more suitable for describing the execution process of the payment access system in the storage medium than the program itself, and the following description will specifically describe the functions of each program module in this embodiment:
as shown in fig. 4, the payment access system 20 includes:
an obtaining module 21, configured to obtain a payment product used by the merchant object as a target payment product;
a determination module 22 for determining a system interface used by the target payment product;
a matching module 23, configured to match a payment product package for the target payment product, where the payment product package is obtained by abstracting a service scene to obtain multiple product scenes, associating a system interface with each product scene, and encapsulating the system interface;
and the access module 24 is used for accessing the merchant object into the matched payment product package.
In one embodiment, the system interface may include, but is not limited to, at least one of: API interface, h5 interface, sdk interface.
In one embodiment, the payment access system may further include: the receiving module is used for receiving a payment request of a user after the merchant object is accessed into the matched payment product package; and the calling module is used for responding to the payment request, calling a payment channel to deduct money from the payment request through a payment product package accessed by the merchant object.
In one embodiment, where the targeted payment product is a POS machine, the associated system interface may be a json message interface in an API interface.
In one embodiment, the payment channel may be a pre-integrated payment channel shared by payment product packages.
In one embodiment, the determination module 22 may include: a first acquisition unit, configured to acquire product information of the target payment product; an extraction unit for extracting hardware information data from the product information; and the determining unit is used for determining the type of the system interface used by the target product according to the hardware information data.
In one embodiment, the matching module 23 may include: a second obtaining unit, configured to obtain identification information of a system interface used by the target product; the calling unit is used for calling a plurality of preset payment product packages; an identification unit configured to identify a payment product package associated with the identification information from the plurality of payment product packages; and the generating unit is used for taking the identified payment product package as the payment product package matched with the target product.
With regard to the apparatus in the above embodiments, the specific manner in which each unit and each module performs operations has been described in detail in the embodiments related to the method, and will not be described in detail herein.
In various implementations of this embodiment.
EXAMPLE III
The embodiment also provides an electronic device, such as a smart phone, a tablet computer, a notebook computer, a desktop computer, a rack-mounted server, a blade server, a tower server or a rack-mounted server (including an independent server or a server cluster composed of a plurality of servers) capable of executing programs, and the like. As shown in fig. 5, the electronic device 2 of the present embodiment at least includes but is not limited to: a memory 21, a processor 22, and a network interface 23 communicatively coupled to each other via a system bus. It should be noted that fig. 5 only shows some of the components, but it should be understood that not all of the shown components are required to be implemented, and more or fewer components may be implemented instead.
In the present embodiment, the memory 21 (i.e., a readable storage medium) includes a flash memory, a hard disk, a multimedia card, a card-type memory (e.g., SD or DX memory, etc.), a Random Access Memory (RAM), a Static Random Access Memory (SRAM), a read-only memory (ROM), an electrically erasable programmable read-only memory (EEPROM), a programmable read-only memory (PROM), a magnetic memory, a magnetic disk, an optical disk, and the like. In some embodiments, the storage 21 may be an internal storage unit of the electronic device 2, such as a hard disk or a memory of the electronic device 2. In other embodiments, the memory 21 may also be an external storage device of the electronic device 2, such as a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), and the like, provided on the electronic device 2. Of course, the memory 21 may also comprise both an internal memory unit of the electronic device 2 and an external memory device thereof. In the present embodiment, the memory 21 is generally used for storing an operating system and various types of application software installed in the electronic device 2. Further, the memory 21 may also be used to temporarily store various types of data that have been output or are to be output.
Specifically, in this embodiment, the processor 22 is configured to execute a program of a payment access method stored in the processor 22, and the program of the payment access method implements the following steps when executed:
step 1: acquiring a payment product used by a merchant object as a target payment product;
step 2: determining a system interface used by the target payment product;
and step 3: matching a payment product package for the target payment product, wherein the payment product package is obtained by abstracting a plurality of product scenes according to service scenes, associating a system interface for each product scene and packaging;
and 4, step 4: and accessing the merchant object into the matched payment product package.
In the above embodiment, a plurality of product scenes are obtained by abstracting the service scenes, and the system interface is associated with each product scene, so that a plurality of payment product packages are obtained by encapsulation, and when a merchant has an access demand, the corresponding payment product package is matched according to the payment product and the system interface used by the merchant, so that the merchant is accessed into the payment system.
The specific embodiment process of the above method steps can be referred to in the first embodiment, and the detailed description of this embodiment is not repeated here.
Example four
The present embodiments also provide a computer readable storage medium, such as a flash memory, a hard disk, a multimedia card, a card type memory (e.g., SD or DX memory, etc.), a Random Access Memory (RAM), a Static Random Access Memory (SRAM), a Read Only Memory (ROM), an Electrically Erasable Programmable Read Only Memory (EEPROM), a Programmable Read Only Memory (PROM), a magnetic memory, a magnetic disk, an optical disk, a server, an App application mall, etc., having stored thereon a computer program that when executed by a processor implements the method steps of:
step 1: acquiring a payment product used by a merchant object as a target payment product;
step 2: determining a system interface used by the target payment product;
and step 3: matching a payment product package for the target payment product, wherein the payment product package is obtained by abstracting a plurality of product scenes according to service scenes, associating a system interface for each product scene and packaging;
and 4, step 4: and accessing the merchant object into the matched payment product package.
In the above embodiment, a plurality of product scenes are obtained by abstracting the service scenes, and the system interface is associated with each product scene, so that a plurality of payment product packages are obtained by encapsulation, and when a merchant has an access demand, the corresponding payment product package is matched according to the payment product and the system interface used by the merchant, so that the merchant is accessed into the payment system.
The specific embodiment process of the above method steps can be referred to in the first embodiment, and the detailed description of this embodiment is not repeated here.
It should be noted that, in this document, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The above-mentioned serial numbers of the embodiments of the present invention are merely for description and do not represent the merits of the embodiments.
Through the above description of the embodiments, those skilled in the art will clearly understand that the method of the above embodiments can be implemented by software plus a necessary general hardware platform, and certainly can also be implemented by hardware, but in many cases, the former is a better implementation manner.
The above description is only a preferred embodiment of the present invention, and not intended to limit the scope of the present invention, and all modifications of equivalent structures and equivalent processes, which are made by using the contents of the present specification and the accompanying drawings, or directly or indirectly applied to other related technical fields, are included in the scope of the present invention.
Claims (10)
1. A payment access method, comprising the steps of:
acquiring a payment product used by a merchant object as a target payment product;
determining a system interface used by the target payment product;
matching a payment product package for the target payment product, wherein the payment product package is obtained by abstracting a plurality of product scenes according to service scenes, associating a system interface for each product scene and packaging;
and accessing the merchant object into the matched payment product package.
2. The method of claim 1, wherein determining a system interface used by the target payment product comprises:
acquiring product information of the target payment product;
extracting hardware information data from the product information;
and determining the type of a system interface used by the target product according to the hardware information data.
3. The method of claim 1, wherein matching a payment product package for the target payment product comprises:
acquiring identification information of a system interface used by the target product;
calling a plurality of preset payment product packages;
identifying a payment product package associated with the identification information from the plurality of payment product packages;
and using the identified payment product package as the payment product package matched with the target product.
4. The method of claim 1, further comprising, after accessing the merchant object to the matching payment package:
receiving a payment request of a user;
and responding to the payment request, and calling a payment channel to deduct money from the payment request through a payment product package accessed by the merchant object.
5. The method of claim 1, prior to matching a payment product package for the target payment product, comprising:
acquiring different bill receiving service scenes;
classifying the bill receiving service scene according to the type of the collected products in the bill receiving service scene;
determining the type of a front-end interface corresponding to each type of order receiving service scene;
and packaging to obtain a plurality of product packages according to each type of order receiving service scene and the type of the corresponding front-end interface, wherein the plurality of product packages are accessed by different merchants according to the type of the used payment products.
6. The method of claim 1, further comprising, after accessing the merchant object to the matching payment package:
receiving a payment request;
determining, in response to the payment request, a payment system with which the payment request is associated;
calling a preset shared payment channel to be associated to the payment system;
and completing the deduction service through the payment system.
7. An electronic device comprising a memory and a processor, wherein the memory is configured to store a payment access system executable by the processor, the payment access system comprising:
the acquisition module is used for acquiring the payment product used by the merchant object as a target payment product;
a determination module for determining a system interface used by the target payment product;
the matching module is used for matching a payment product package for the target payment product, wherein the payment product package is obtained by abstracting a plurality of product scenes according to service scenes and associating system interfaces for the product scenes, and is obtained by packaging;
and the access module is used for accessing the merchant object into the matched payment product package.
8. The electronic device of claim 7, wherein the determining module comprises:
a first acquisition unit, configured to acquire product information of the target payment product;
an extraction unit for extracting hardware information data from the product information;
and the determining unit is used for determining the type of the system interface used by the target product according to the hardware information data.
9. A computer device, comprising: memory, processor and computer program stored on the memory and executable on the processor, characterized in that the processor implements the steps of the method according to any of claims 1 to 6 when executing the computer program.
10. A non-transitory computer readable storage medium, having a computer program stored thereon, wherein the computer program, when executed by a processor, implements the steps of the method of any of claims 1 to 6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011542635.6A CN112561507A (en) | 2020-12-23 | 2020-12-23 | Payment access method, electronic device and computer readable storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011542635.6A CN112561507A (en) | 2020-12-23 | 2020-12-23 | Payment access method, electronic device and computer readable storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112561507A true CN112561507A (en) | 2021-03-26 |
Family
ID=75031848
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011542635.6A Pending CN112561507A (en) | 2020-12-23 | 2020-12-23 | Payment access method, electronic device and computer readable storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112561507A (en) |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150039455A1 (en) * | 2013-07-31 | 2015-02-05 | Sergio Luciani | Universal Interface Card Swipe Terminal Point of Sale System With Multiple Mobile Wallets/Payment Applications |
| CN111415140A (en) * | 2020-02-27 | 2020-07-14 | 上海商米科技集团股份有限公司 | Aggregated payment management method, server and computer storage medium |
-
2020
- 2020-12-23 CN CN202011542635.6A patent/CN112561507A/en active Pending
Patent Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20150039455A1 (en) * | 2013-07-31 | 2015-02-05 | Sergio Luciani | Universal Interface Card Swipe Terminal Point of Sale System With Multiple Mobile Wallets/Payment Applications |
| CN111415140A (en) * | 2020-02-27 | 2020-07-14 | 上海商米科技集团股份有限公司 | Aggregated payment management method, server and computer storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP6761056B2 (en) | Resource processing method and equipment | |
| CN111062619B (en) | Merchant identification method and device, electronic equipment and storage medium | |
| EP3792860B1 (en) | Resource transfer method and device, computer device and storage medium | |
| CN106096926B (en) | Event processing method, device, electronic device and storage medium | |
| CN110264332A (en) | The method, apparatus and electronic equipment that account is entered an item of expenditure in the accounts | |
| CN113205402A (en) | Account checking method and device, electronic equipment and computer readable medium | |
| CN111026769A (en) | Working method of dual-core front-end system and related equipment thereof | |
| CN111415146A (en) | Resource data processing method, device and equipment | |
| CN109614263B (en) | Disaster tolerance data processing method, device and system | |
| CN111539730A (en) | Data processing method and device based on block chain and electronic equipment | |
| CN112633874B (en) | Code scanning transaction processing method, electronic device and computer readable storage medium | |
| CN109582401B (en) | Promotion picture generation method and device, storage medium and computer equipment | |
| CN108881390A (en) | the cloud platform deployment method, device and equipment of electronic account service | |
| CN112561507A (en) | Payment access method, electronic device and computer readable storage medium | |
| CN108876339B (en) | E-pet transaction method and device based on certificate | |
| CN117333186A (en) | Acquisition method of credit information and establishment method and device of credit management and control rule | |
| CN112115738A (en) | Image identification method and device applied to browser end | |
| CN115391343A (en) | Bill data processing method and device, electronic equipment and storage medium | |
| CN109634963B (en) | Policy data processing method and device and readable storage medium | |
| CN113537994A (en) | Resource transfer method, device, equipment and medium | |
| CN109799981B (en) | Integrated system and method based on execution chain | |
| CN112463409A (en) | Data interaction method and device, electronic equipment and computer readable storage medium | |
| CN107169760B (en) | Mapping card management method based on multiple media, data processing method and device | |
| US11574293B2 (en) | Information processing apparatus and method, and information processing system | |
| CN109754189A (en) | A kind of distribution method of fabrication task, a kind of acquisition methods, computer installation and the computer readable storage medium of fabrication task |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |