<aside> 📢 Notice: This document was generated by Dibsy Product Team for internal use only./

</aside>

Google Pay Overview

Current Flow with QCB SDK

  1. QCB generates uses a private-public key pair in QCB isolated environment.
  2. QCB shares the public key with merchant to upload to Google Pay console.
  3. All payment tokens generated are signed with QCB shared public key.
  4. Encrypted payload sent to QCB via the SDK can only be used by QCB to decrypt and process payments.

Challenges:

Despite these advancements, several challenges hinder the full utilization of the QPay Network:

  1. Credit card implementation: As the payload is signed with QCB public key, merchants will be only be able to process it via QCB, and this would hinder processing existing payments for credit cards via the Visa and Mastercard networks. Building a full debit card and credit card implementation requires an expertise in cryptography tokenization which most merchants lack.
  2. Limited Scope of SDK for websites: The current SDK supports mobile app integrations but lacks the capability for web payment integrations. This limitation restricts the use of Apple Pay, Google Pay, and Samsung Pay on websites, which forms a significant component of e-commerce transactions.
  3. Migration Burdens for Merchants: The integration process for applications is particularly burdensome for merchants. This complexity can deter smaller merchants from adopting the QPay Network due to the technical and financial resources required.

Improvements

  1. Key Pair Generation (One-Time Setup)
  1. Receiving Encrypted Token (Per Transaction)

When a user pays, Google Pay generates an encrypted payment token using the public key generated in the first step. This token is passed from Dibsy to QCB for decryption and processing.