Krungsri Beyond Procure

Leveraging the data will be utilized and increased its lead generation. Leads are the qualified prospects who can become our customers. One of the solutions is the APIs Connection that can help to be blend with other elements such as information or data, transaction.
 

Use case for Krungsri Beyond Procure

General seller and buyer model case:

  • Seller issues Invoice/Tax invoice and presents to Buyer via Bill sender bank for payment collection.
  • ​Buyer receives Invoice/Tax invoice and additional documents via Bill receiver bank and accept/dispute the presentment.
  • ​Buyer makes a payment for accepted presentment via Payer bank.
  • ​Seller receives a payment via Payee bank and issues eReceipt for received payment.

BOT_flow-(1).png

 
Presentment flow
 
Beyond-Procure-1-2_V3-2.png
 
  1. Seller requests for presentment through a UI provided at front-end application and specify information for presentment entry (e.g. Buyer, Document number, amount, relate documents)
  2. Validate seller eligibility in using the service.
  3. Partner application invoke process for Presentment entry request
  4. Krungsri API validates Presentment entry request which may result in the following scenarios:
  5. Success: Presentment reference number will be responded. Partner application prompt submission result to Seller.
    Fail: Error will be returned.
  6. Partner application invokes Document upload request (if any), Krungsri API submit presentment entry to buyer.
  7. Buyer reviews Presentment details and choose whether to:
    Accept: the presentment entry in order to proceed to payment.
    Dispute: the presentment with remark to inform seller about incorrect detail.
  8. Krungsri API updates presentment entry status to “FNLD” for Seller after buyer ACCEPT presentment entry.
In case of Dispute (Replace) for RD and non-RD type
  1. 1 Krungsri API updates Presentment entry status to “RFSD” and partner’s application with reason remark which partner application can prompt it to Seller for replacement.
  2. 2 Seller review and edit presentment detail or document via partner application.
  3. 3 Partner application invoke Presentment entry request with operation flag Replace.
  4. 4 Krungsri API responds with a new presentment reference number.
  5. 5 Partner application invoke a new Document upload request (if any), Krungsri API resubmits presentment entry to buyer for reconsideration.
  6. 6 Krungsri API cancel the replaced presentment entry.
In case of Dispute (Amend) for only non-RD type
  1. 1 Krungsri API updates Presentment entry status to “RFSD” and partner’s application with reason remark which partner application can prompt it to Seller for replacement.
  2. 2 Seller review and edit presentment detail or document via partner application.
  3. 3 Seller edits presentment entry details. Partner application invoke Presentment entry request with operation flag Amend and submits edited detail.
  4. 4 Krungsri API validate instruction and responds with edited entry detail.
  5. 5 Partner application invoke a new Document upload request (if any), Krungsri API resubmits presentment entry to buyer for reconsideration.
In case of Cancellation
  1. Seller selects presentment entry to be cancelled via partner’s application. Partner’s application invokes Presentment cancellation request by referring to Presentment reference number.
  2. Krungsri API validate the instruction if the presentment entry can be cancelled.
  3. Krungsri API submit presentment cancellation request to buyer and responds the result to partner’s application which can prompt the result to seller.
Payment flow
 
Payment-flow.png
  1. Payer requests for payment by selecting “ACCEPTED” presentment entry(s) to be paid through a UI provided at front-end application and review information for payment entry (e.g., Payee, presentment entries, total amount, payment method, effective date)
    Krungsri channel invoke process for Payment entry (Beyond Procure Payment information entry request)
    Krungsri channel processes payment as instructed on effective date which may result in the following scenarios:
    - PROCESSING: Payment will be processed on effective date by Krungsri channel
    - ERROR: Error will be returned.
  2. Payee bank receives and reviews payment information.
  3. Payee bank submits update payment entry status to Krungsri API. Krungsri API callback with both updated payment status and updated submission status.
In case of Cancellation
  1. Payer selects payment entry to be cancelled on Krungsri channel.
  2. Krungsri channel invokes Payment information entry cancellation request to Krungsri API.
  3. Krungsri API validates the request and responds with entry status which Krungsri channel will prompt to Payer.
  4. Payer could reselect presentment entries to be paid in order to reprocess the payment transaction.
eReceipt flow
 
eReceipt-1-1.PNG
  1. Payee requests for eReceipt issuing through a UI provided at front-end application and specify information for 
    eReceipt entry (e.g. Payer, Invoice number, Total amount, VAT amount).
  2. Validate payee’s instruction eligibility.
  3. Partner application invoke process for eReceipt entry (Beyond Procure eReceipt entry submission request).
  4. Krungsri API validates eReceipt entry submission request which may result in the following scenarios:
    Success: eReceipt reference number will be responded to partner application
    Fail: Error will be returned.
  5. Application invokes eReceipt document upload (if any). Krungsri API submits eReceipt entry to Payer.
  6. Krungsri API responds eReceipt entry submission result to partner application to be prompted to payee.
In case of Replacement
  1. 1 Payee requests for eReceipt replacement through a UI provided via partner application.
       Partner application invokes eReceipt entry submission with operation flag replace (“RPC”).
  2. 2 Krungsri API validates instruction which may result in the following scenarios:
  3. 3 Success: Krungsri API responds with a new eReceipt reference number.
       Fail: Error will be returned and the status of the old eReceipt will remain unchanged.
       Partner application could prompt replacing result to Payee.
  4. 4 Partner application invoke a new Document upload (if any), Krungsri API resubmits eReceipt entry to payer.
  5. 5 Krungsri API cancel the replaced eReceipt entry.

• Related API

View API Catalogs

   

Seq No. API Name API Endpoints
AEMarket Presentment EntryPOST /rest/api/v1/emarket/presentment/entry
BEMarket Presentment Document UploadPOST /rest/api/v1/emarket/presentment/document/upload
CEMarket Presentment Entry CancellationPOST /rest/api/v1/emarket/presentment/entry/cancellation
DMerchant eReceipt Entry SubmissionPOST /rest/api/v1/emarket/payment/receipt/entry
EMerchant e-Receipt Document UploadPOST /rest/api/v1/emarket/payment/ereceipt/document/upload

Technical Detail

Content