Create an API design for third-party integration for payments.

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.