MyPaymentNetwork

Notice of technologies being phased out:

Support for TLS 1.0 and 1.1 are being phased out of our systems and we cannot guarantee availability of our systems using these technologies. As such, you should test your application's HTTP library against the URL https://www.howsmyssl.com/a/check and make sure the tls_version is TLS 1.2. If it is not, you should configure the library until it does, or write your application using a different HTTP library. Thank you

Webhooks

Notifications (Postbacks)

Once the payment has successfully posted, we will notify you of payment. We will send a notification of money successfully moving when a payment enters the “Pending” state (funds authorized, but not taken) or the “Settled” state (funds withdrawn). We will only send you one notification per payment.

We will abstain from sending you notifications for a variety of situations in attempt to help you make good software design choices on your side.

We will NOT send you notifications for failed payments for the following reasons:

  • Your software needs to be able to handle the case of the user simply closing the browser window on our side.
  • Users do not need historical information of failed payments.
  • Our software will allow them to try again in the case of a decline. You do not need to handle the retry loop.
  • The need for a decline notification is typically due to using a wait semaphore1 implementer’s side. This can be a very bad design as the user would be stuck in “waiting for payment to complete” even after closing out a browser window and coming back!

We will NOT send you notifications for refund or voids for the following reasons:

  • Refunds may happen as much as months after the original payment and the context/reasons for doing so may not be clear enough to make programmatic decisions on.
  • Partial refunds complicate what exactly is being refunded.
  • Refunds need to be invoked by someone in a position of power on your side, so there is little need to automate its behavior.

A program designed to accept a notification and act upon the data inside it is called a notification receiver. This program needs to have a publicly accessible URL that accepts a standard HTTP POST. It is not required to set up encryption on this connection as we do not send any sensitive2 data in the transmission.

The following data is sent to you in the transmission:

Key Value
transaction_id Unique, SchoolPay assigned identifier on the transaction.
posted_amount The amount you sent to us with the customer.
total_amount This is the full amount of the transaction.
Items This is the JSON-encoded array you sent at the beginning of the payment process.

Please check out the SchoolPay Checkout sample program for a practical demonstration of how to use our service.

1 Value that controls program execution flow
2 “Sensitive” terms of PCI compliance. Implementers may deem some pieces of information as sensitive and would then elect to use an encrypted connection to communicate with SchoolPay.