Shrusti

Shrusti Mathur
PayPal is an e-commerce business allowing payments and money transfers to be made through the Internet. Online money transfers serve as electronic alternatives to traditional paper methods such as checks and money orders.

A PayPal account can be funded with an electronic debit from a bank account or by a credit card. The recipient of a PayPal transfer can either request a check from PayPal, establish their own PayPal deposit account or request a transfer to their bank account.

PayPal performs payment processing for online vendors, auction sites, and other commercial users, for which it charges a fee. It may also charge a fee for receiving money, proportional to the amount received. The fees depend on the currency used, the payment option used, the country of the sender, the country of the recipient, the amount sent and the recipient's account type.[2] In addition, eBay purchases made by credit card through PayPal may incur extra fees if the buyer and seller use different currencies.

On October 3, 2002, PayPal became a wholly-owned subsidiary of eBay.[3] Its corporate headquarters are in San Jose, California, United States at eBay's North First Street satellite office campus. The company also has significant operations in Omaha, Nebraska; Scottsdale, Arizona; and Austin, Texas in the U.S., Chennai, Dublin, Berlin and Tel-Aviv. As of July 2007, across Europe, PayPal also operates as a Luxembourg-based bank.

On March 17, 2010, PayPal entered into an agreement with China UnionPay (CUP), China's bankcard association, to allow Chinese consumers to use PayPal to shop online.[citation needed] PayPal is planning to expand its workforce in Asia to 2,000 by the end of the year 2010.[4][5]

Between December 4-9, 2010, PayPal service's were distrupted due to Denial of Service attacks organized by Anonymous in retaliation to PayPal's decision to freeze the account of WikiLeaks citing terms of use violations over the publication of leaked US diplomatic cables


The current incarnation of PayPal is the result of a March 2000 merger between Confinity and X.com.[10] Confinity was founded in December 1998 by Max Levchin, Peter Thiel, Luke Nosek, and Ken Howery, initially as a Palm Pilot payments and cryptography company.[11] X.com was founded by Elon Musk in March 1999, initially as an Internet financial services company. Both Confinity and X.com launched their websites in late 1999. Both companies were located on University Avenue in Palo Alto. Confinity's website was initially focused on reconciling beamed payments from Palm Pilots[12] with email payments as a feature and X.com's website initially featured financial services with email payments as a feature.

At Confinity, many of the initial recruits were alumni of The Stanford Review, also founded by Peter Thiel, and most early engineers hailed from the University of Illinois at Urbana-Champaign, recruited by Max Levchin. On the X.com side, Elon Musk recruited a wide range of technical and business personnel, including many that were critical to the combined company's success, such as Amy Klement, Sal Giambanco, Roelof Botha[13] of Sequoia Capital, Sanjay Bhargava and Jeremy Stoppelman.[14]

To block potentially fraudulent access by automated systems, PayPal used a system (see CAPTCHA) of making the user enter numbers from a blurry picture, which they coined the Gausebeck-Levchin test.[15]

eBay watched the rise in volume of its online payments and realized the fit of an online payment system with online auctions. eBay purchased Billpoint in May 1999, prior to the existence of PayPal. eBay made Billpoint its official payment system, dubbing it "eBay Payments," but cut the functionality of Billpoint by narrowing it to only payments made for eBay auctions. For this reason, PayPal was listed in many more auctions than Billpoint. In February 2000, the PayPal service had an average of approximately 200,000 daily auctions while Billpoint (in beta) had only 4,000 auctions.[16][17][18] By April 2000, more than 1,000,000 auctions promoted the PayPal service.[19] PayPal was able to turn the corner and become the first dot-com to IPO after the September 11 attacks.

Instant Payment Notification (IPN) is a message service that notifies you of events related to PayPal transactions. You can use it to automate back-office and administrative functions, such as fulfilling orders, tracking customers, and providing status and other information related to a transaction.

*

IPN Overview
*

IPN Protocol and Architecture
*

A Sample IPN Message and Response
*

Non-IPN Notification Mechanisms

IPN Overview

IPN notifies you when an event occurs that affects a transaction. Typically, these events represent various kinds of payments; however, the events may also represent authorizations, Fraud Management Filter actions and other actions, such as refunds, disputes, and chargebacks.

IPN is a message service that PayPal uses to notify you about events, such as

*

Instant payments, including Express Checkout, Adaptive Payments, and direct credit card payments, and authorizations, which indicate a sale whose payment has not yet been collected
*

eCheck payments and associated status, such as pending, completed, or denied, and payments pending for other reasons, such as those being reviewed for potential fraud
*

Recurring payment and subscription actions
*

Chargebacks, disputes, reversals, and refunds associated with a transaction

In many cases, the action that causes the event, such as a payment, occurs on your website; however, your website is not the only source of events. In many cases, events can be generated by Website Payment Standard buttons, the PayPal API, or by PayPal itself.

You detect and process IPN messages with a listener, sometimes called a handler, which is a script or program that you write. It waits for messages and passes them to various back-end or administrative processes that respond the messages. PayPal provides sample code that you can modify to implement a listener that detects IPN messages.

The actions to take when your listener is notified of an event are specific to your needs. Examples of the kinds of actions you might take when your listener receives an IPN message include the following:

*

Trigger order fulfillment or enable media downloads when a check clears or a payment is made
*

Update your list of customers
*

Update accounting records
*

Create specialized “to do” lists based on the kind of event

You are typically notified of events by email as well, but the IPN message service enables you to automate your response to events. The following diagram shows how events can occur and how PayPal responds with IPN messages that it sends to your listener:


The diagram shows requests and responses, which are the result of processing button clicks or API operations on PayPal. PayPal sends an IPN message when it sends a response to a request. The IPN message is not actually part of the response sent to your website. Rather, the IPN message is sent to the your listener, which allows you to take actions that are not directly tied to the operation of your website.
Note:

The diagram does not show the IPN authentication protocol messages that validate the IPN message.

IPN is an asynchronous message service, meaning that messages are not synchronized with actions on your website. Thus, listening for an IPN message does not increase the time it takes to complete a transaction on your website.

The IPN message service does not assume that all messages will be received by your listener in a timely manner. Because the internet is not 100% reliable, messages can become lost or delayed. To handle the possibility of transmission and receipt delays or failures, the IPN message service implements a retry mechanism that resends messages at various intervals until you acknowledge that the message has successfully been received. Messages may be resent for up to four days after the original message.
Note:

Unless you are certain that a failure occurred on the the Internet, the most likely cause of lost, delayed, or duplicate IPN messages is faulty logic in the listener itself.

Because messages can be delivered at any time, your listener must always be available to receive and process messages; however, the retry mechanism also handles the possibility that your listener could become swamped or stop responding.

The IPN message service should not be considered a real-time service. Your checkout flow should not wait on an IPN message before it is allowed to complete. If your website waits for an IPN message, checkout processing may be delayed due to system load and become more complicated because of the possibility of retries.
IPN Protocol and Architecture

IPN is designed to be secure, reliable, and asynchronous. To meet these requirements, the protocol requires you to acknowledge receipt of IPN messages. The IPN service provides a retry mechanism to handle cases in which a message is not acknowledged; for example, when a transmission or receipt failure occurs.

When you enable IPN, PayPal sends messages to the IPN listener at the URL you specify in your account’s profile. You can override the URL to associate other IPN listeners with specific transactions. In this case, you specify the listener’s URL when you set up a Website Payment Standard button or a PayPal API operation.

The IPN protocol consists of three steps:

1.

PayPal sends your IPN listener a message that notifies you of the event
2.

Your listener sends the complete unaltered message back to PayPal; the message must contain the same fields in the same order and be encoded in the same way as the original message
3.

PayPal sends a single word back, which is either VERIFIED if the message originated with PayPal or INVALID if there is any discrepancy with what was originally sent

Your listener must respond to each message, whether or not you intend to do anything with it. If you do not respond, PayPal assumes that the message was not received and resends the message. PayPal continues to resend the message periodically until your listener sends the correct message back, although the interval between resent messages increases each time. The message can be resent for up to four days.

This resend algorithm can lead to situations in which PayPal resends the IPN message while you are sending back the original message. In this case, you should send your response again, to cover the possibility that PayPal did not actually receive your response the first time. You should also ensure that you do not process the transaction associated with the message twice.
Important:

PayPal expects to receive a response to an IPN message within 30 seconds. Your listener should not perform time-consuming operations, such as creating a process, before responding to the IPN message.

After PayPal verifies the message, there are additional checks that your listener or back-end or administrative software must take:

*

Verify that you are the intended recipient of the IPN message by checking the email address in the message; this handles a situation where another merchant could accidentally or intentionally attempt to use your listener.
*

Avoid duplicate IPN messages. Check that you have not already processed the transaction identified by the transaction ID returned in the IPN message. You may need to store transaction IDs returned by IPN messages in a file or database so that you can check for duplicates. If the transaction ID sent by PayPal is a duplicate, you should not process it again.
*

Because IPN messages can be sent at various stages in a transaction’s progress, make sure that the transaction’s payment status is “completed” before enabling shipment of merchandise or allowing the download of digital media.
*

Verify that the payment amount actually matches what you intend to charge. Although not technically an IPN issue, if you do not encrypt buttons, it is possible for someone to capture the original transmission and change the price. Without this check, you could accept a lesser payment than what you expected.

IPN Messages Generated by Website Payments Standard

PayPal generates an IPN message when your customer clicks a Website Payments Standard payment button, such as a Buy Now button, and completes the transaction on PayPal. You can use this notification to kick-off order fulfillment, enable digital media downloads, store information in a customer relationship management (CRM) or accounting system, and so on.

The following diagram shows both the web flow and the IPN message authentication protocol:


The numbers in diagram correspond to the following steps:

1.

The button action initiates a payment that completes on PayPal
2.

PayPal sends your IPN listener a message that notifies you of the event
3.

Your listener sends the complete unaltered message back to PayPal; the message must contain the same fields in the same order and be encoded in the same way as the original message
4.

PayPal sends a single word back, which is either VERIFIED if the message originated with PayPal or INVALID if there is any discrepancy with what was originally sent

Your IPN listener must implement the IPN authentication protocol (steps 2, 3, and 4 in this diagram). After successfully completing the protocol, your back-office or administrative process vets the contents of the message and responds appropriately. For example, if the payment status for the transaction is “Completed,” your system can print a packing list or email a password to your customer for downloading digital media.
IPN Messages Generated by APIs

PayPal generates an IPN message when you invoke an API operation, such as DoExpressCheckoutPayment of DoDirectPayment during checkout or an Adaptive Payments Pay, Preapproval, or ExecutePayment API operation. You can use this notification to kick-off order fulfillment, enable digital media downloads, store information in a customer relationship management (CRM) or accounting system, and so on.

The following diagram shows both the web flow and the IPN message authentication protocol:


The numbers in the diagram correspond to the following steps:

1.

The API operation initiates a payment on PayPal.
2.

PayPal sends your IPN listener a message that notifies you of the event
3.

Your listener sends the complete unaltered message back to PayPal; the message must contain the same fields in the same order and be encoded in the same way as the original message
4.

PayPal sends a single word back, which is either VERIFIED if the message originated with PayPal or INVALID if there is any discrepancy with what was originally sent

Your IPN listener must implement the IPN authentication protocol (steps 2, 3, and 4 in this diagram). After successfully completing the protocol, your back-office or administrative process vets the contents of the message and responds appropriately. For example, if the payment status for the transaction is “Completed,” your system can print a packing list or email a password to your customer for downloading digital media.
IPN Messages Generated by a Back-Office Procedure

PayPal generates an IPN message when you perform actions that invoke the PayPal API, regardless of whether it is from your website or from a back-office or administrative procedure. You can use this notification to trigger an email to your customer, store information in a CRM or accounting system, and so on.

The following diagram shows both an administrative web flow and the IPN message authentication protocol:


The numbers in diagram correspond to the following steps:

1.

Your back-office or administrative process invokes a PayPal API operation; for example, it could invoke the RefundTransaction API operation when your employee issues a refund.
2.

PayPal sends your IPN listener a message that notifies you of the event
3.

Your listener sends the complete unaltered message back to PayPal; the message must contain the same fields in the same order and be encoded in the same way as the original message
4.

PayPal sends a single word back, which is either VERIFIED if the message originated with PayPal or INVALID if there is any discrepancy with what was originally sent

Your IPN listener implements the IPN authentication protocol (steps 2, 3, and 4 in this diagram). After successfully completing the protocol, your listener or back-office or administrative process vets the contents of the message and responds appropriately. For example, your system can notify the customer of the refund by email.
PayPal-Initiated IPN Messages

Some IPN messages generated by PayPal are not directly associated with a web flow. PayPal generates an IPN message when external events arise that might affect a transaction, such as disputes, chargebacks, echeck clearing, and various recurring payment and subscription events.

In this case, events that trigger IPN messages are not directly related to actions on your website. The following diagram shows the steps your listener must take:


The numbers in diagram correspond to the following steps, which implement the IPN message authentication protocol:

1.

PayPal sends your IPN listener a message that notifies you of the event
2.

Your listener sends the complete unaltered message back to PayPal; the message must contain the same fields in the same order and be encoded in the same way as the original message
3.

PayPal sends a single word back, which is either VERIFIED if the message originated with PayPal or INVALID if there is any discrepancy with what was originally sent

After successfully completing the protocol, your back-office or administrative process vets the contents of the message and responds appropriately. For example, the IPN messages may trigger you to print shipping labels for items whose payments have cleared, investigate disputes and chargebacks, store information in an accounting system, and so on.
 
Last edited by a moderator:
PayPal is an e-commerce business allowing payments and money transfers to be made through the Internet. Online money transfers serve as electronic alternatives to traditional paper methods such as checks and money orders.

A PayPal account can be funded with an electronic debit from a bank account or by a credit card. The recipient of a PayPal transfer can either request a check from PayPal, establish their own PayPal deposit account or request a transfer to their bank account.

PayPal performs payment processing for online vendors, auction sites, and other commercial users, for which it charges a fee. It may also charge a fee for receiving money, proportional to the amount received. The fees depend on the currency used, the payment option used, the country of the sender, the country of the recipient, the amount sent and the recipient's account type.[2] In addition, eBay purchases made by credit card through PayPal may incur extra fees if the buyer and seller use different currencies.

On October 3, 2002, PayPal became a wholly-owned subsidiary of eBay.[3] Its corporate headquarters are in San Jose, California, United States at eBay's North First Street satellite office campus. The company also has significant operations in Omaha, Nebraska; Scottsdale, Arizona; and Austin, Texas in the U.S., Chennai, Dublin, Berlin and Tel-Aviv. As of July 2007, across Europe, PayPal also operates as a Luxembourg-based bank.

On March 17, 2010, PayPal entered into an agreement with China UnionPay (CUP), China's bankcard association, to allow Chinese consumers to use PayPal to shop online.[citation needed] PayPal is planning to expand its workforce in Asia to 2,000 by the end of the year 2010.[4][5]

Between December 4-9, 2010, PayPal service's were distrupted due to Denial of Service attacks organized by Anonymous in retaliation to PayPal's decision to freeze the account of WikiLeaks citing terms of use violations over the publication of leaked US diplomatic cables


The current incarnation of PayPal is the result of a March 2000 merger between Confinity and X.com.[10] Confinity was founded in December 1998 by Max Levchin, Peter Thiel, Luke Nosek, and Ken Howery, initially as a Palm Pilot payments and cryptography company.[11] X.com was founded by Elon Musk in March 1999, initially as an Internet financial services company. Both Confinity and X.com launched their websites in late 1999. Both companies were located on University Avenue in Palo Alto. Confinity's website was initially focused on reconciling beamed payments from Palm Pilots[12] with email payments as a feature and X.com's website initially featured financial services with email payments as a feature.

At Confinity, many of the initial recruits were alumni of The Stanford Review, also founded by Peter Thiel, and most early engineers hailed from the University of Illinois at Urbana-Champaign, recruited by Max Levchin. On the X.com side, Elon Musk recruited a wide range of technical and business personnel, including many that were critical to the combined company's success, such as Amy Klement, Sal Giambanco, Roelof Botha[13] of Sequoia Capital, Sanjay Bhargava and Jeremy Stoppelman.[14]

To block potentially fraudulent access by automated systems, PayPal used a system (see CAPTCHA) of making the user enter numbers from a blurry picture, which they coined the Gausebeck-Levchin test.[15]

eBay watched the rise in volume of its online payments and realized the fit of an online payment system with online auctions. eBay purchased Billpoint in May 1999, prior to the existence of PayPal. eBay made Billpoint its official payment system, dubbing it "eBay Payments," but cut the functionality of Billpoint by narrowing it to only payments made for eBay auctions. For this reason, PayPal was listed in many more auctions than Billpoint. In February 2000, the PayPal service had an average of approximately 200,000 daily auctions while Billpoint (in beta) had only 4,000 auctions.[16][17][18] By April 2000, more than 1,000,000 auctions promoted the PayPal service.[19] PayPal was able to turn the corner and become the first dot-com to IPO after the September 11 attacks.

Instant Payment Notification (IPN) is a message service that notifies you of events related to PayPal transactions. You can use it to automate back-office and administrative functions, such as fulfilling orders, tracking customers, and providing status and other information related to a transaction.

*

IPN Overview
*

IPN Protocol and Architecture
*

A Sample IPN Message and Response
*

Non-IPN Notification Mechanisms

IPN Overview

IPN notifies you when an event occurs that affects a transaction. Typically, these events represent various kinds of payments; however, the events may also represent authorizations, Fraud Management Filter actions and other actions, such as refunds, disputes, and chargebacks.

IPN is a message service that PayPal uses to notify you about events, such as

*

Instant payments, including Express Checkout, Adaptive Payments, and direct credit card payments, and authorizations, which indicate a sale whose payment has not yet been collected
*

eCheck payments and associated status, such as pending, completed, or denied, and payments pending for other reasons, such as those being reviewed for potential fraud
*

Recurring payment and subscription actions
*

Chargebacks, disputes, reversals, and refunds associated with a transaction

In many cases, the action that causes the event, such as a payment, occurs on your website; however, your website is not the only source of events. In many cases, events can be generated by Website Payment Standard buttons, the PayPal API, or by PayPal itself.

You detect and process IPN messages with a listener, sometimes called a handler, which is a script or program that you write. It waits for messages and passes them to various back-end or administrative processes that respond the messages. PayPal provides sample code that you can modify to implement a listener that detects IPN messages.

The actions to take when your listener is notified of an event are specific to your needs. Examples of the kinds of actions you might take when your listener receives an IPN message include the following:

*

Trigger order fulfillment or enable media downloads when a check clears or a payment is made
*

Update your list of customers
*

Update accounting records
*

Create specialized “to do” lists based on the kind of event

You are typically notified of events by email as well, but the IPN message service enables you to automate your response to events. The following diagram shows how events can occur and how PayPal responds with IPN messages that it sends to your listener:


The diagram shows requests and responses, which are the result of processing button clicks or API operations on PayPal. PayPal sends an IPN message when it sends a response to a request. The IPN message is not actually part of the response sent to your website. Rather, the IPN message is sent to the your listener, which allows you to take actions that are not directly tied to the operation of your website.
Note:

The diagram does not show the IPN authentication protocol messages that validate the IPN message.

IPN is an asynchronous message service, meaning that messages are not synchronized with actions on your website. Thus, listening for an IPN message does not increase the time it takes to complete a transaction on your website.

The IPN message service does not assume that all messages will be received by your listener in a timely manner. Because the internet is not 100% reliable, messages can become lost or delayed. To handle the possibility of transmission and receipt delays or failures, the IPN message service implements a retry mechanism that resends messages at various intervals until you acknowledge that the message has successfully been received. Messages may be resent for up to four days after the original message.
Note:

Unless you are certain that a failure occurred on the the Internet, the most likely cause of lost, delayed, or duplicate IPN messages is faulty logic in the listener itself.

Because messages can be delivered at any time, your listener must always be available to receive and process messages; however, the retry mechanism also handles the possibility that your listener could become swamped or stop responding.

The IPN message service should not be considered a real-time service. Your checkout flow should not wait on an IPN message before it is allowed to complete. If your website waits for an IPN message, checkout processing may be delayed due to system load and become more complicated because of the possibility of retries.
IPN Protocol and Architecture

IPN is designed to be secure, reliable, and asynchronous. To meet these requirements, the protocol requires you to acknowledge receipt of IPN messages. The IPN service provides a retry mechanism to handle cases in which a message is not acknowledged; for example, when a transmission or receipt failure occurs.

When you enable IPN, PayPal sends messages to the IPN listener at the URL you specify in your account’s profile. You can override the URL to associate other IPN listeners with specific transactions. In this case, you specify the listener’s URL when you set up a Website Payment Standard button or a PayPal API operation.

The IPN protocol consists of three steps:

1.

PayPal sends your IPN listener a message that notifies you of the event
2.

Your listener sends the complete unaltered message back to PayPal; the message must contain the same fields in the same order and be encoded in the same way as the original message
3.

PayPal sends a single word back, which is either VERIFIED if the message originated with PayPal or INVALID if there is any discrepancy with what was originally sent

Your listener must respond to each message, whether or not you intend to do anything with it. If you do not respond, PayPal assumes that the message was not received and resends the message. PayPal continues to resend the message periodically until your listener sends the correct message back, although the interval between resent messages increases each time. The message can be resent for up to four days.

This resend algorithm can lead to situations in which PayPal resends the IPN message while you are sending back the original message. In this case, you should send your response again, to cover the possibility that PayPal did not actually receive your response the first time. You should also ensure that you do not process the transaction associated with the message twice.
Important:

PayPal expects to receive a response to an IPN message within 30 seconds. Your listener should not perform time-consuming operations, such as creating a process, before responding to the IPN message.

After PayPal verifies the message, there are additional checks that your listener or back-end or administrative software must take:

*

Verify that you are the intended recipient of the IPN message by checking the email address in the message; this handles a situation where another merchant could accidentally or intentionally attempt to use your listener.
*

Avoid duplicate IPN messages. Check that you have not already processed the transaction identified by the transaction ID returned in the IPN message. You may need to store transaction IDs returned by IPN messages in a file or database so that you can check for duplicates. If the transaction ID sent by PayPal is a duplicate, you should not process it again.
*

Because IPN messages can be sent at various stages in a transaction’s progress, make sure that the transaction’s payment status is “completed” before enabling shipment of merchandise or allowing the download of digital media.
*

Verify that the payment amount actually matches what you intend to charge. Although not technically an IPN issue, if you do not encrypt buttons, it is possible for someone to capture the original transmission and change the price. Without this check, you could accept a lesser payment than what you expected.

IPN Messages Generated by Website Payments Standard

PayPal generates an IPN message when your customer clicks a Website Payments Standard payment button, such as a Buy Now button, and completes the transaction on PayPal. You can use this notification to kick-off order fulfillment, enable digital media downloads, store information in a customer relationship management (CRM) or accounting system, and so on.

The following diagram shows both the web flow and the IPN message authentication protocol:


The numbers in diagram correspond to the following steps:

1.

The button action initiates a payment that completes on PayPal
2.

PayPal sends your IPN listener a message that notifies you of the event
3.

Your listener sends the complete unaltered message back to PayPal; the message must contain the same fields in the same order and be encoded in the same way as the original message
4.

PayPal sends a single word back, which is either VERIFIED if the message originated with PayPal or INVALID if there is any discrepancy with what was originally sent

Your IPN listener must implement the IPN authentication protocol (steps 2, 3, and 4 in this diagram). After successfully completing the protocol, your back-office or administrative process vets the contents of the message and responds appropriately. For example, if the payment status for the transaction is “Completed,” your system can print a packing list or email a password to your customer for downloading digital media.
IPN Messages Generated by APIs

PayPal generates an IPN message when you invoke an API operation, such as DoExpressCheckoutPayment of DoDirectPayment during checkout or an Adaptive Payments Pay, Preapproval, or ExecutePayment API operation. You can use this notification to kick-off order fulfillment, enable digital media downloads, store information in a customer relationship management (CRM) or accounting system, and so on.

The following diagram shows both the web flow and the IPN message authentication protocol:


The numbers in the diagram correspond to the following steps:

1.

The API operation initiates a payment on PayPal.
2.

PayPal sends your IPN listener a message that notifies you of the event
3.

Your listener sends the complete unaltered message back to PayPal; the message must contain the same fields in the same order and be encoded in the same way as the original message
4.

PayPal sends a single word back, which is either VERIFIED if the message originated with PayPal or INVALID if there is any discrepancy with what was originally sent

Your IPN listener must implement the IPN authentication protocol (steps 2, 3, and 4 in this diagram). After successfully completing the protocol, your back-office or administrative process vets the contents of the message and responds appropriately. For example, if the payment status for the transaction is “Completed,” your system can print a packing list or email a password to your customer for downloading digital media.
IPN Messages Generated by a Back-Office Procedure

PayPal generates an IPN message when you perform actions that invoke the PayPal API, regardless of whether it is from your website or from a back-office or administrative procedure. You can use this notification to trigger an email to your customer, store information in a CRM or accounting system, and so on.

The following diagram shows both an administrative web flow and the IPN message authentication protocol:


The numbers in diagram correspond to the following steps:

1.

Your back-office or administrative process invokes a PayPal API operation; for example, it could invoke the RefundTransaction API operation when your employee issues a refund.
2.

PayPal sends your IPN listener a message that notifies you of the event
3.

Your listener sends the complete unaltered message back to PayPal; the message must contain the same fields in the same order and be encoded in the same way as the original message
4.

PayPal sends a single word back, which is either VERIFIED if the message originated with PayPal or INVALID if there is any discrepancy with what was originally sent

Your IPN listener implements the IPN authentication protocol (steps 2, 3, and 4 in this diagram). After successfully completing the protocol, your listener or back-office or administrative process vets the contents of the message and responds appropriately. For example, your system can notify the customer of the refund by email.
PayPal-Initiated IPN Messages

Some IPN messages generated by PayPal are not directly associated with a web flow. PayPal generates an IPN message when external events arise that might affect a transaction, such as disputes, chargebacks, echeck clearing, and various recurring payment and subscription events.

In this case, events that trigger IPN messages are not directly related to actions on your website. The following diagram shows the steps your listener must take:


The numbers in diagram correspond to the following steps, which implement the IPN message authentication protocol:

1.

PayPal sends your IPN listener a message that notifies you of the event
2.

Your listener sends the complete unaltered message back to PayPal; the message must contain the same fields in the same order and be encoded in the same way as the original message
3.

PayPal sends a single word back, which is either VERIFIED if the message originated with PayPal or INVALID if there is any discrepancy with what was originally sent

After successfully completing the protocol, your back-office or administrative process vets the contents of the message and responds appropriately. For example, the IPN messages may trigger you to print shipping labels for items whose payments have cleared, investigate disputes and chargebacks, store information in an accounting system, and so on.

Hey shrusti, i would like to tell you that you are doing very nice work and i really appreciate it. Well, i have also got some important information on Paypal and would like to share it with you which would help many people here.
 

Attachments

Back
Top