Integration Testing Scenarios

Following document lists recommended test cases that PSPs/Merchants should test while and after integrating with BPG API.

We recommend to test the scenarios with both Demo and Production environments.

Under each scenario we provide a description of expected behavior

Payment paid correctly

  1. New Payment
  2. Payment is paid correct amount
  3. BPG API will send one Payment notification with status CONFIRMED, paidAmount and paidBtc will match what was requested

Payment paid after expiration

  1. New Payment
  2. Expiration time passes
  3. API will send one Payment notification with status EXPIRED, paidAmount and paidBtc will be zero
  4. Some time passes
  5. BPG API will wait few blockchain notifications and send Anomaly notification with paidBtc matching the BTC amount that was paid and paidAmount that is converted using exchange rate from the moment when payment was received
  6. Payment will not be updated

Underpayment

  1. New Payment
  2. Payment is paid too little
  3. API will send one Payment notification with status UNDERPAID, paidAmount and paidBtc will match what was paid
  4. Expiration time passes
  5. API will send INVALID notification, paidAmount and paidBtc will not change

Underpayment and the rest was paid

  1. New Payment
  2. Payment is paid too little
  3. API will send one Payment notification with status UNDERPAID, paidAmount and paidBtc will match what was paid
  4. Before expiration time passes, user pays the rest.
  5. API will send CONFIRMED notification, paidAmount and paidBtc will match what was originally requested

Payment expired

  1. New Payment
  2. Expiration time passes
  3. API will send EXPIRED notification, paidAmount and paidBtc will be zero.

Overpayment (single transaction)

  1. New Payment
  2. Payment is paid too much
  3. API will send INVALID notification, paidAmount and paidBtc will match what was paid

Overpayment (two transactions)

  1. New Payment
  2. Payment is paid too little
  3. API will send UNDERPAID notification, paidAmount and paidBtc will match what was paid.
  4. User notices the error and sends the missing BTC, due to mistake user sends too much
  5. API will send INVALID notification, paidAmount and paidBtc will match total that was paid

Unconfirmed Payment

  1. New Payment
  2. Payment is paid correct amount
  3. API decides that due to high amount of Payment it requires one network notification
  4. API will send UNCONFIRMED notification, paidAmount and paidBtc will match what was requested.
  5. Few minutes pass (API receives network confirmation about incoming transaction)
  6. API will send CONFIRMED notification , paidAmount and paidBtc will match what was requested.

Note: Creating payments for high amounts is the easiest situation to reproduce UNCONFIRMED state, API analyzes multiple factors to decide if incoming transaction requires network confirmation so you can trigger this case when testing other scenarios

Unconfirmed Payment invalidated

(This case is very hard to reproduce, please contact support)

  1. New Payment
  2. Payment is paid correct amount
  3. API decides that due to high amount of Payment it requires one network notification
  4. API will UNCONFIRMED notification, paidAmount and paidBtc will match what was requested.
  5. API notices that the incoming transaction was fraudulent and is removed from blockchain
  6. API will send INVALID notification , paidAmount and paidBtc will be zero.