Clarifications/Product description:-

So is it like I am the product manager of a payment instrument product and now I need to design a API for 3rd party applications (like online storefronts) for integrating our payment instrument so that users who try to purchase products from the online storefront can pay via this payment instrument? Yes the understanding is correct.

Now there can be many 3rd party applications like POS, on line storefronts – for the scope of the question lets focus on Storefronts as in POS usecase mostly card based payments are used.

Also now from payment instrument perspective it can be a credit card/ debit card kind of instrument or a independent new payment. Considering debit card/ credit card call goes via networks and quite a std process, I ll focus on an independent payment instrument like pay later or wallet –> as these are upcoming in the market.

Also by API design : we are focusing on the deisgn of the way the payment instrument and 3rd party application can interact? Yes

Users of this payment integration:

Online storefront : who are integrating this API

End users: who are paying for the service / product via this payment instruement

Product attributes imp for a payment integration:

?Success rates: Every storefront wants a payment instrument that has high success rates so that customers don’t abandon the cart as there payment failed. Also users want the payment experience to smooth.

Consistency: The usecase details with money and thus at all times it is important that the accurate user information is taken for debiting the right amount.

Availability:

Time taken to confirm the payment/ Steps should be minimum.

Easy to integrate: merchants want a integration that is quick to integrate with minimum steps

Scalable

Goal: any specific goal u want me to focus on? No u choose. Ok considering we are focusing on payments and there is high competition in payment space, focus on retaining users who transact via the payment instrument.

Prio of attributes: Compliance (as it is about payment), Impact on merchants , Relevance to the goal

?Success rate:  compliance: low, impact on merchant: high, goal: high

Consistency : Compliance: high, merchant: med, goal: high

Availability:  compliance: med merchant: med (they have other alternatives), goal: med

Time taken to confirm the payment: Compliance: low, merchant: med, goal: high

Ease to integrate compliance: low, merchant: high, high

Scalable complaince: low, merchant: high, goal: high

Secure: compliance: high, merchant: high, goal: high

So would prioritize a design that has:

?High success rates

Consistent

Scalable

Secure

Design:

?Scalable and consistent design would like to go for a distributed system design where focus is on CP (consistent partition tolerance)

For ensuring high success rate: to build fault tolerence via retry mechanisms

Secure: will implement hashing to ensure data integrity and encryption to keep the information confidential and private.

API suite:-

?Eligibility : to determine if the customer is eligible for this payment instrument

Request details

Phone number

Amount

Unique id

Hash

Response

Eligibility code

unique id

Hash

Authentication call : via OTP (encrypted call)

Request details

Phone number

unique id

Hash

Response

OTP

unique id

Hash

Session id

Debit call (encrypted call)

Request details

Phone number

session id

amount

hash

unique id

Response

response code

unique id

hash

Refund API

Inquiry API:

Design:

Provide your thoughts on my approach to answering this Microsoft technical interview question.

1. CLARIFY:
   1. Do you have a specific type of payment in mind (B2C, B2B)? You choose.
   2. Do you have a specific type of third party (ERP system, accounting system, payment aggregator, etc.) in mind? You choose.
   3. Is there a specific goal you have in mind for this payment? You choose.
   4. Is this API using existing Microsoft technology? Should I presume it’s designed by Microsoft? Owned by Microsoft but you can choose whether it leverages existing technology.
2. BACKGROUND: Microsoft is a technology company whose mission is to empower every person and organization to achieve more. They are widely known for their software packages: Word, Outlook, PPT and Excel, Mirosoft Windows (its operating system) and Internet Explorer browser that are widely used in both personal and business devices.
3. GOAL: The API I’d like to design is focused on enabling faster / easier payment to Microsoft for its software packages.
4. USER GROUPS:  For this goal, I’d specifically like to focus on businesses purchasing Microsoft software for their company – i.e. B2B payments. There are a few user groups we can think of. For this goal, I’d like to focus on ERP systems, as I believe large companies are likely purchasing multiple licenses for software use from Microsoft (given the number of employees) and a payments API could be most useful to them to manage their spend. Most large companies use ERP systems.
   1. ERP System: Enterprise resource planning software companies mainly used by middle – large companies to manage all of their business processes. Part of their function focuses on procurement, payments and accounting. For example – Oracle.
   2. Procurement Software: Could be cloud based procurement solution that enable buyers (i.e. companies) and suppliers (i.e. Microsoft) to come onto a common platform and make the procurement process more efficient. Payment is part of the procurement process (i.e. Procure to Pay), and payment information for invoices is stored on this software. Procurement software may be integrated into a broader ERP system. Generally used by middle – large companies. For example – SAP Ariba.
   3. Accounting Software: Software that helps companies record financial transactions and potentially analyze their spend. Can be accessed online. Generally used by smaller companies. For example, QuickBooks, FreshBooks or Xero.
5. ERP / PAYMENTS JOURNEY: Let’s assume that this company is paying for each individual license for Microsoft Office for each employee (v. a global contract covering all licenses). This company has global offices.
   1. Microsoft works with Accounts Payable to set itself up in ERP system. Provides them with payment details, including bank account, payment method, etc. Note – Microsoft has to ensure it is set up for payment from multiple countries because the company (i.e. buyer) has global presence.
   2. Each time, Tech department sets up a new laptop, they go onto company’s internal software request website to request purchase of Microsoft Office / download to laptop.
   3. Notice of license purchase gets sent to ERP system.
   4. ERP registers purchase of Microsoft Office with subsequent details (# of licenses, cost, country, time, etc.).
   5. ERP pushes payment to specified Microsoft entity (depending on what country the license was purchased in) at the end of each month for the total number of licenses purchased.
6. PAIN POINTS:
   1. Global Presence: Given that the buyer has global presence, Microsoft has to manage multiple set ups as a supplier in the ERP system because it is being paid under different legal entities depending on the country of origin.
   2. Bank Detail Maintenance: Microsoft must track details of multiple Microsoft legal entities across the globe and make sure its details as the supplier in the ERP system are up to date. For example, if it changes it bank account in UK, it needs to make sure that the buyer has those updated details to avoid delayed payment.
   3. Payment Methods: Microsoft must ensure that its payment methods are listed correctly for each individual account. Accounts may have multiple payment methods. Ex. a Microsoft in the UK may have an ACH for certain type of purchase and Wire for another type. These payment methods may also correspond to different bank accounts.
   4. Delayed Payment: Microsoft payments may get delayed in the ERP system. Accounts Payable may either be manually holding the payment for review (for example, suspicious activity, incorrect amount, tax review, etc.) or the ERP may not be able to push it through because details in the system are incorrect.
   5. Incorrect Payment: Payment each month is incorrect: wrong amount, wrong entity, wrong method of payment, etc.
   6. Reconciliation: ERP must automatically reconcile payments to Microsoft each month with the correct licenses in each country. If details from purchase are missing / incorrect, ERP is unable to reconcile correctly for Accounts Payable.
7. PRIORITIZE PAIN POINTS:

   1. Pain Point	Impact to ERP
      Global Presence	High
      Bank Detail Maintenance	High
      Payment Methods	Medium
      Delayed Payment	Medium
      Incorrect Payment	Medium
      Reconciliation	Low

8. SOLUTIONS: 
   1. Global Microsoft Supplier Details API: Microsoft builds an API that integrates into 3rd party ERP systems (starting with the most popular) that automatically sets them as a supplier in the system.
   2. Payments Notification API: Microsoft builds an API that automatically tracks payments from buyers worldwide. It tells Microsoft if the payment is sent, delayed, etc. – i.e. what the status of the payment is in a buyer’s ERP system.
   3. Payment Incorrect API: Microsoft builds an API that automatically alerts an ERP system if a payment is incorrect. Reconciles payment details internal to Microsoft with payment sent from ERP.
   4. Payment Reconciliation API: Microsoft builds an API that automatically reconciles payments made from buyers via an ERP system with internal Microsoft payment details. The API senses when the buyer’s payment (i.e. the ERP’s payment) does not match Microsoft. Alert is sent back to ERP (i.e. Accounts Payable) if there are issues.
9. SOLUTION PRIORTIZATION: Given the prioritization of pain points and the solution prioritization, I’d focus on the Global Microsoft Supplier Details API.

   1. Solution	Impact to ERP / Buyer	Cost to Microsoft
      Global Microsoft Supplier Details API	High	Low
      Payments Notification API	Low	Low
      Payment Incorrect API	Medium	High
      Payment Reconciliation API	High	High

10. SOLUTION DEEP DIVE: Global Microsoft Supplier Details API passes details for each legal entity by country for Microsoft that an ERP system needs to send payments. These details include: legal entity name, tax ID, billing address, bank account (rounting number, account number, etc.), payment method for bank. If Microsoft has to change bank details or payment details for a certain country, the API automatically sends those updated details to an ERP.  That way, Microsoft avoids manual processes of having to update bank accounts and payment details worldwide with each buyer.
11. METRICS:
    1. # of buyers integrated with
    2. # of ERP systems integrated with
    3. Average time saved for AP setup with buyer
    4. # of avoided payment delays because of automated set up / maintenance
12. LIMITATIONS:
    1. Integrating with each ERP system takes a lot of time / resources / cost. Would have to start with biggest / most popular ones.
    2. May be difficulties maintaining records across the globe if markets have varying degrees of information they need.
    3. Presumably this API would work in real time but if there are every delays in updating correct bank or payment details from Microsoft to ERP, payments could get stuck.