Systems and methods for using a domain-specific security sandbox to facilitate secure transactions

• US 8,364,959 B2
• Filed: 05/26/2010
• Issued: 01/29/2013
• Est. Priority Date: 05/26/2010
• Status: Active Grant

• Current Assignee: Google LLC (Alphabet Inc.)
• Original Assignee: Google Inc. (Alphabet Inc.)
• Inventors: Bhanoo, Hemant Madhav, Bayes, Luke, Mills, Allan Stephan
• Primary Examiner(s): Dada, Beemnet
• Assistant Examiner(s): GYORFI, THOMAS A
• Application Number:
  US12/788,173
• Publication Number:
  US 20110296529A1
• Time in Patent Office: 979 Days
• Field of Search: 713/168, 713/180, 705/64, 705/75, 705/77, 718/101, 709/203
• US Class Current: 713/168
• CPC Class Codes: G06Q 20/3267 In-app payments
• CPC Class Codes: G06Q 20/356 Aspects of software for card payments
• CPC Class Codes: G06Q 20/40 Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
• CPC Class Codes: G07F 7/0826 Embedded security module
• CPC Class Codes: H04L 63/04 for providing a confidential data exchange among entities communicating through data packet networks

Abstract

Computer systems, methods, and computer readable media for facilitating a secure transaction are provided in which a client application is executed on a client computer. The client application initiates a request to a first domain comprising (i) a credential for the client application, (ii) a transaction identifier that uniquely identifies the request, and (iii) optionally, an identification of a user of the client application. Responsive to this request, the client receives a validated transaction module from the first domain. The client application loads the validated transaction module into a separate domain security sandbox that is segregated from memory space in which the client application is run. The validated transaction module conducts a validated transaction between the second domain and the validated transaction module. Separately, through the client application, a determination is made as to whether the transaction is complete by querying the first domain.

Claims

1. A computer system for facilitating a secure transaction, the computer system comprising:

one or more processing units;

a memory, coupled to at least one of the one or more processing units, the memory storing instructions that are executed by at least one of the one or more processing units, the instructions comprising;

(A) executing a client application, wherein the client application is executed directly from a local data store or is executed from a remote client application server;

(B) generating, through the client application, at a time when the client application is executing, a request associated with a secure in-application transaction, wherein the request comprises (i) a credential for the client application, (ii) a transaction identifier that uniquely identifies the request, and (iii) optionally, an identification of a user of the client application;

(C) submitting the request for the secure in-application transaction over the Internet or a computer network to a first domain that has an unrestrictive first cross-domain policy;

(D) receiving, responsive to the submitting (C), a validated transaction module from the first domain wherein the source URL of the transaction module is identified as the first domain;

(E) causing the client application to execute the validated transaction module such that the validated transaction module is loaded into a separate domain security sandbox within said memory, wherein

the separate domain security sandbox is segregated from memory space in said memory in which the client application is run,

the separate domain security sandbox is associated with, and limited to, programs that identify their source URL as being the first domain,

the validated transaction module is executed by the causing (E) such that the identity of the source URL of the validated transaction module is not altered or destroyed, and

the validated transaction module does not grant the client application the power to introspect the validated transaction module;

(F) issuing, from the validated transaction module while it is executing in the separate domain security sandbox, a transaction call to a second domain, wherein the second domain has a second cross-domain policy that limits interaction between the second domain and programs external to the second domain to those external programs whose source URL is the first domain;

(G) conducting a validated transaction between the second domain and the validated transaction module; and

(H) determining, through the client application, by querying the first domain, whether the transaction was completed, thereby facilitating a secure transaction.

2. The computer system of claim 1, the computer system further comprising a display having a screen real estate, wherein, upon the executing (A), the client application is manifested on a portion of said screen real estate and wherein the validated transaction module is manifested on a subset of said portion of said screen real estate.

3. The computer system of claim 1, wherein the secure in-application transaction is an in-game transaction to buy an in-game upgrade using an account associated with the identity of the user.

4. The computer system of claim 3, wherein the in-game upgrade is a level unlock, a purchase of virtual equipment, a purchase of a virtual special weapon, a purchase of a cheat, or a purchase of virtual currency.

5. The computer system of claim 1, wherein the client application is a social networking application, a financial services application, an accounting application, or a tax preparation application.

6. The computer system of claim 1, wherein the first domain and the second domain are hosted by the same server that is accessible to the computer system over the Internet or the computer network.

7. The computer system of claim 1, wherein the first domain and the second domain are each hosted by a separate server and are each accessible to the computer system over the Internet or the computer network.

8. The computer system of claim 1, wherein the client application is a FLASH application and wherein the validated transaction module is a FLASH SWF application that is loaded by the client application during the causing (E).

9. A method for facilitating a secure transaction comprising:

(A) executing a client application on a suitably programmed computer, wherein the client application is executed directly from a local data store or is executed from a remote client application server;

(B) generating on the suitably programmed computer, through the client application, at a time when the client application is executing, a request associated with a secure in-application transaction, wherein the request comprises (i) a credential for the client application, (ii) a transaction identifier that uniquely identifies the request, and (iii) optionally, an identification of a user of the client application;

(C) submitting, from the suitably programmed computer, the request for the secure in-application transaction over the Internet or a computer network to a first domain that has an unrestrictive first cross-domain policy;

(D) receiving, at the suitably programmed computer, responsive to the submitting (C), a validated transaction module from the first domain wherein the source URL of the transaction module is identified as the first domain;

(E) causing, using the suitably programmed computer, the client application to execute the validated transaction module such that the validated transaction module is loaded into a separate domain security sandbox, wherein

the separate domain security sandbox is segregated from memory space in which the client application is run,

the separate domain security sandbox is associated with, and limited to, programs that identify their source URL as being the first domain,

the validated transaction module is executed by the causing (E) such that the identity of the source URL of the validated transaction module is not altered or destroyed, and

the validated transaction module does not grant the client application the power to introspect the validated transaction module;

(F) issuing, from the validated transaction module while it is executing in the separate domain security sandbox of the suitably programmed computer, a transaction call to a second domain, wherein the second domain has a second cross-domain policy that limits interaction between the second domain and programs external to the second domain to those external programs whose source URL is the first domain;

(G) conducting, using the suitably programmed computer, a validated transaction between the second domain and the validated transaction module; and

(H) determining, through the client application running on the suitably programmed computer, by querying the first domain, whether the transaction was completed, thereby facilitating a secure transaction.

10. The method of claim 9, wherein, upon the executing (A), the client application is manifested on a portion of a screen real estate and wherein the validated transaction module is manifested on a subset of said portion of said screen real estate.

11. The method of claim 9, wherein the secure in-application transaction is an in-game transaction to buy an in-game upgrade using an account associated with the identity of the user.

12. The method of claim 11, wherein the in-game upgrade is a level unlock, a purchase of virtual equipment, a purchase of a virtual special weapon, a purchase of a cheat, or a purchase of virtual currency.

13. The method of claim 9, wherein the client application is a social networking application, a financial services application, an accounting application, or a tax preparation application.

14. The method of claim 9, wherein the first domain and the second domain are hosted by the same server.

15. The method of claim 9, wherein the first domain and the second domain are each hosted by a separate server.

16. The method of claim 9, wherein the client application is a FLASH application and wherein the validated transaction module is a FLASH SWF application that is loaded by the client application during the causing (E).

17. A computer program product for use in conjunction with a computer system, the computer program product comprising a non-transitory computer readable storage medium and a computer program mechanism embedded therein, the computer program mechanism for facilitating a secure transaction, the computer program mechanism comprising computer executable instructions for:

(A) executing a client application on the computer system, wherein the client application is executed directly from a local data store or is executed from a remote client application server;

(B) generating on the computer system, through the client application, at a time when the client application is executing, a request associated with a secure in-application transaction, wherein the request comprises (i) a credential for the client application, (ii) a transaction identifier that uniquely identifies the request, and (iii) optionally, an identification of a user of the client application;

(C) submitting, from the computer system, the request for the secure in-application transaction over the Internet or a computer network to a first domain that has an unrestrictive first cross-domain policy;

(D) receiving, at the computer system, responsive to the submitting (C), a validated transaction module from the first domain wherein the source URL of the transaction module is identified as the first domain;

(E) causing, using the computer system, the client application to execute the validated transaction module such that the validated transaction module is loaded into a separate domain security sandbox, wherein

the separate domain security sandbox is segregated from memory space in which the client application is run,

the separate domain security sandbox is associated with, and limited to, programs that identify their source URL as being the first domain,

the validated transaction module is executed by the causing (E) such that the identity of the source URL of the validated transaction module is not altered or destroyed, and

the validated transaction module does not grant the client application the power to introspect the validated transaction module;

(F) issuing, from the validated transaction module while it is executing in the separate domain security sandbox of the computer system, a transaction call to a second domain, wherein the second domain has a second cross-domain policy that limits interaction between the second domain and programs external to the second domain to those external programs whose source URL is the first domain;

(G) conducting, using the computer system, a validated transaction between the second domain and the validated transaction module; and

(H) determining, through the client application running on the computer system, by querying the first domain, whether the transaction was completed, thereby facilitating a secure transaction.

18. A system comprising:

(A) means for executing a client application on a suitably programmed computer, wherein the client application is executed directly from a local data store or is executed from a remote client application server;

(B) means for generating on the suitably programmed computer, through the client application, at a time when the client application is executing, a request associated with a secure in-application transaction, wherein the request comprises (i) a credential for the client application, (ii) a transaction identifier that uniquely identifies the request, and (iii) optionally, an identification of a user of the client application;

(C) means for submitting, from the suitably programmed computer, the request for the secure in-application transaction over the Internet or a computer network to a first domain that has an unrestrictive first cross-domain policy;

(D) receiving, at the suitably programmed computer, responsive to the submitting (C), a validated transaction module from the first domain wherein the source URL of the transaction module is identified as the first domain;

(E) causing, using the suitably programmed computer, the client application to execute the validated transaction module such that the validated transaction module is loaded into a separate domain security sandbox, wherein

the separate domain security sandbox is segregated from memory space in which the client application is run,

the separate domain security sandbox is associated with, and limited to, programs that identify their source URL as being the first domain,

the validated transaction module is executed by the causing (E) such that the identity of the source URL of the validated transaction module is not altered or destroyed, and

the validated transaction module does not grant the client application the power to introspect the validated transaction module;

(F) issuing, from the validated transaction module while it is executing in the separate domain security sandbox of the suitably programmed computer, a transaction call to a second domain, wherein the second domain has a cross-domain policy that limits interaction between the second domain and programs external to the second domain to those external programs whose source URL is the first domain;

(G) conducting, using the suitably programmed computer, a validated transaction between the second domain and the validated transaction module; and

(H) determining, through the client application running on the suitably programmed computer, by querying the first domain, whether the transaction was completed, thereby facilitating a secure transaction.

19. A computer system for facilitating a secure transaction, the computer system comprising:

one or more processing units;

a memory, coupled to at least one of the one or more processing units, the memory storing instructions that are executed by at least one of the one or more processing units, wherein the memory comprises;

a first domain characterized by a first cross-domain policy that is unrestrictive;

a second domain characterized by a second cross-domain policy that limits interaction between the second domain and programs external to the second domain to those external programs whose source URL is the first domain;

a database of valid application credentials;

a transaction database that is readable from the first domain and the second domain;

a transaction module; and

instructions for;

(A) receiving, at the first domain, over the Internet or a computer network, a request from a client application running on a client computer, wherein the request is associated with a secure in-application transaction and wherein the request comprises (i) a credential for the client application, (ii) a transaction identifier that uniquely identifies the request, and (iii) an identification of a user of the client application;

(B) verifying the credential for the client application against the database of valid application credentials;

(C) keying the request into the transaction database;

(D) providing, from the first domain, the transaction module to the client computer;

(E) receiving, at the second domain, a transaction call that originates from the transaction module executing on the client computer, wherein the source URL of the transaction module complies with the second cross-domain policy;

(F) conducting a validated transaction between the second domain and the transaction module running on the client computer;

(G) storing, at the second domain, a record of the completed transaction in the transaction database;

(H) receiving, at the first domain, a query from the client application running on the client computer as to whether the transaction has been completed, wherein the query includes the transaction identifier that uniquely identifies the request;

(I) determining, at the first domain, by looking up the transaction identifier in the transaction database, whether the transaction has been completed; and

(J) notifying, responsive to the receiving (H) and the determining (I), the client application running on the client computer of the status of the transaction.

20. The computer system of claim 19, wherein the secure in-application transaction is an in-game transaction to buy an in-game upgrade using an account associated with the identity of the user.

21. The computer system of claim 20, wherein the in-game upgrade is a level unlock, a purchase of virtual equipment, a purchase of a virtual special weapon, a purchase of a cheat, or a purchase of virtual currency.

22. The computer system of claim 19, wherein the client application is a social networking application, a financial services application, an accounting application, or a tax preparation application.

23. The computer system of claim 19, wherein the first domain and the second domain are hosted by the same server that is accessible to the client computer over the Internet or the computer network.

24. The computer system of claim 19, wherein

the first domain is hosted by a first server,

the second domain is hosted by a second server,

the first server and the second server are each accessible to the client computer over the Internet or the computer network,

the memory comprises a first memory resident in the first server and a second memory resident in the second server,

the first cross-domain policy, the database of valid application credentials, and the unbranded transaction module are resident in the first memory of the first server,

the second cross-domain policy is resident in the memory of the second server, and

the first server and the second server each have access to the transaction database.

25. The computer system of claim 19, wherein the client application is a FLASH application and wherein the transaction module is a FLASH SWF application.

26. The computer system of claim 19, wherein the receiving (H), determining (I), and notifying (J) are repeated until the secure transaction is deemed completed.

27. A computer system for facilitating a secure transaction, the computer system comprising:

one or more processing units;

a memory, coupled to at least one of the one or more processing units, the memory storing instructions that are executed by at least one of the one or more processing units, the instructions comprising;

(A) executing a client application, wherein the client application is executed directly from a local data store or is executed from a remote client application server;

(B) generating, through the client application, at a time when the client application is executing, a first request associated with a secure in-application transaction;

(C) submitting the first request for the secure in-application transaction over the Internet or a computer network to a first domain that has an unrestrictive first cross-domain policy;

(D) receiving, responsive to the submitting (C), a request module, wherein the source URL of the request module is identified as the first domain;

(E) causing the client application to execute the request module such that the request module is loaded into a first domain security sandbox within said memory, wherein

the first domain security sandbox is segregated from memory space in said memory in which the client application is run,

the first domain security sandbox is associated with, and limited to, programs that identify their source URL as being the first domain,

the request module is executed by the causing (E) such that the identity of the source URL of the request module is not altered or destroyed, and

the request module does not grant the client application the power to introspect the request module;

(F) generating, through the request module, at a time when the request application is executing, a second request associated with the secure in-application transaction;

wherein the second request comprises (i) a credential for the client application, (ii) a transaction identifier that uniquely identifies the second request, and (iii) optionally, an identification of a user of the client application;

(G) submitting the second request for the secure in-application transaction over the Internet or the computer network to a second domain that has a second cross-domain policy that limits interaction between the second domain and programs external to the second domain to those external programs whose source URL is the first domain;

(H) receiving, responsive to the submitting (G), a transaction module from the second domain wherein the source URL of the transaction module is identified as the second domain;

(I) causing the client application to execute the transaction module such that the transaction module is loaded into a second domain security sandbox within said memory, wherein

the second domain security sandbox is segregated from memory space in said memory in which the client application is run,

the second domain security sandbox is associated with, and limited to, programs that identify their source URL as being the second domain,

the transaction module is executed by the causing (I) such that the identity of the source URL of the transaction module is not altered or destroyed, and the transaction module does not grant the client application the power to introspect the transaction module;

(J) issuing, from the transaction module while it is executing in the second domain security sandbox, a transaction call to a third domain, wherein the third domain has a cross-domain policy that limits interaction between the third domain and programs external to the third domain to those external programs whose source URL is the second domain;

(K) conducting a validated transaction between the third domain and the transaction module; and

(L) determining, through the client application, by querying the first domain, whether the transaction was completed, thereby facilitating a secure transaction.

28. The computer system of claim 27, the computer system further comprising a display having a screen real estate, wherein, upon the executing (A), the client application is manifested on a portion of said screen real estate and wherein the transaction module is manifested on a subset of said portion of said screen real estate.

29. The computer system of claim 27, wherein the secure in-application transaction is an in-game transaction to buy an in-game upgrade using an account associated with the identity of the user.

30. The computer system of claim 29, wherein the in-game upgrade is a level unlock, a purchase of virtual equipment, a purchase of a virtual special weapon, a purchase of a cheat, or a purchase of virtual currency.

31. The computer system of claim 27, wherein the client application is a social networking application, a financial services application, an accounting application, or a tax preparation application.

32. The computer system of claim 27, wherein the first domain, the second domain, and the third domain are hosted by the same server that is accessible to the computer system over the Internet or the computer network.

33. The computer system of claim 27, wherein the first domain, the second domain, and the third domain are each hosted by a separate server and are each accessible to the computer system over the Internet or the computer network.

34. The computer system of claim 27, wherein the client application is a FLASH application and wherein the transaction module is a FLASH SWF application that is loaded by the client application during the causing (I).

35. A method for facilitating a secure transaction, the method comprising:

(A) executing a client application, on a suitably programmed computer, wherein the client application is executed directly from a local data store or is executed from a remote client application server;

(B) generating, through the client application, on the suitably programmed computer, at a time when the client application is executing, a first request associated with a secure in-application transaction;

(C) submitting, using the suitably programmed computer, the first request for the secure in-application transaction over the Internet or a computer network to a first domain that has an unrestrictive first cross-domain policy;

(D) receiving, at the suitably programmed computer, responsive to the submitting (C), a request module, wherein the source URL of the request module is identified as the first domain;

(E) causing the client application to execute, using the suitably programmed computer, the request module such that the request module is loaded into a first domain security sandbox, wherein

the first domain security sandbox is segregated from memory space in which the client application is run,

the first domain security sandbox is associated with, and limited to, programs that identify their source URL as being the first domain,

the request module is executed by the causing (E) such that the identity of the source URL of the request module is not altered or destroyed, and

the request module does not grant the client application the power to introspect the request module;

(F) generating, through the request module, using the suitably programmed computer, at a time when the request application is executing, a second request associated with the secure in-application transaction;

wherein the second request comprises (i) a credential for the client application, (ii) a transaction identifier that uniquely identifies the second request, and (iii) optionally, an identification of a user of the client application;

(G) submitting, using the suitably programmed computer, the second request for the secure in-application transaction over the Internet or the computer network to a second domain that has a second cross-domain policy that limits interaction between the second domain and programs external to the second domain to those external programs whose source URL is the first domain;

(H) receiving, responsive to the submitting (G), at the suitably programmed computer, a transaction module from the second domain wherein the source URL of the transaction module is identified as the second domain;

(I) causing, using the suitably programmed computer, the client application to execute the transaction module such that the transaction module is loaded into a second domain security sandbox within said memory, wherein

the second domain security sandbox is segregated from memory space in said memory in which the client application is run,

the second domain security sandbox is associated with, and limited to, programs that identify their source URL as being the second domain,

the transaction module is executed by the causing (I) such that the identity of the source URL of the transaction module is not altered or destroyed, and the transaction module does not grant the client application the power to introspect the transaction module;

(J) issuing, using the suitably programmed computer, from the transaction module while it is executing in the second domain security sandbox, a transaction call to a third domain, wherein the third domain has a cross-domain policy that limits interaction between the third domain and programs external to the third domain to those external programs whose source URL is the second domain;

(K) conducting, using the suitably programmed computer, a validated transaction between the third domain and the transaction module; and

(L) determining, using the suitably programmed computer, through the client application, by querying the first domain, whether the transaction was completed, thereby facilitating a secure transaction.

36. The method of claim 35, wherein, upon the executing (A), the client application is manifested on a portion of a screen real estate and wherein the transaction module is manifested on a subset of said portion of said screen real estate.

37. The method of claim 35, wherein the secure in-application transaction is an in-game transaction to buy an in-game upgrade using an account associated with the identity of the user.

38. The method of claim 37, wherein the in-game upgrade is a level unlock, a purchase of virtual equipment, a purchase of a virtual special weapon, a purchase of a cheat, or a purchase of virtual currency.

39. The method of claim 35, wherein the client application is a social networking application, a financial services application, an accounting application, or a tax preparation application.

40. The method of claim 35, wherein the first domain, the second domain, and the third domain are hosted by the same server.

41. The method of claim 37, wherein the first domain and the second domain are each hosted by a separate server.

42. The method of claim 37, wherein the client application is a FLASH application and wherein the transaction module is a FLASH SWF application that is loaded by the client application during the causing (I).

43. A computer program product for use in conjunction with a computer system, the computer program product comprising a non-transitory computer readable storage medium and a computer program mechanism embedded therein, the computer program mechanism for facilitating a secure transaction, the computer program mechanism comprising computer executable instructions for:

(A) executing a client application, on said computer system, wherein the client application is executed directly from a local data store or is executed from a remote client application server;

(B) generating, through the client application, on the computer system, at a time when the client application is executing, a first request associated with a secure in-application transaction;

(C) submitting, using the computer system, the first request for the secure in-application transaction over the Internet or a computer network to a first domain that has an unrestrictive first cross-domain policy;

(D) receiving, at the computer system, responsive to the submitting (C), a request module, wherein the source URL of the request module is identified as the first domain;

(E) causing the client application to execute, using the computer system, the request module such that the request module is loaded into a first domain security sandbox,

wherein the first domain security sandbox is segregated from memory space in which the client application is run,

the first domain security sandbox is associated with, and limited to, programs that identify their source URL as being the first domain,

the request module is executed by the causing (E) such that the identity of the source URL of the request module is not altered or destroyed, and

the request module does not grant the client application the power to introspect the request module;

(F) generating, through the request module, using the computer system, at a time when the request application is executing, a second request associated with the secure in-application transaction;

wherein the second request comprises (i) a credential for the client application, (ii) a transaction identifier that uniquely identifies the second request, and (iii) optionally, an identification of a user of the client application;

(G) submitting, using the computer system, the second request for the secure in-application transaction over the Internet or the computer network to a second domain that has a second cross-domain policy that limits interaction between the second domain and programs external to the second domain to those external programs whose source URL is the first domain;

(H) receiving, responsive to the submitting (G), at the computer system, a transaction module from the second domain wherein the source URL of the transaction module is identified as the second domain;

(I) causing, using the computer system, the client application to execute the transaction module such that the transaction module is loaded into a second domain security sandbox within said memory, wherein

the second domain security sandbox is segregated from memory space in said memory in which the client application is run,

the second domain security sandbox is associated with, and limited to, programs that identify their source URL as being the second domain,

the transaction module is executed by the causing (I) such that the identity of the source URL of the transaction module is not altered or destroyed, and the transaction module does not grant the client application the power to introspect the transaction module;

(J) issuing, using the computer system, from the transaction module while it is executing in the second domain security sandbox, a transaction call to a third domain, wherein the third domain has a cross-domain policy that limits interaction between the third domain and programs external to the third domain to those external programs whose source URL is the second domain;

(K) conducting, using the computer system, a validated transaction between the third domain and the transaction module; and

(L) determining, using the computer system, through the client application, by querying the first domain, whether the transaction was completed, thereby facilitating a secure transaction.

44. A system comprising:

(A) means for executing a client application, on a suitably programmed computer, wherein the client application is executed directly from a local data store or is executed from a remote client application server;

(B) means for generating, through the client application, on the suitably programmed computer, at a time when the client application is executing, a first request associated with a secure in-application transaction;

(C) means for submitting, using the suitably programmed computer, the first request for the secure in-application transaction over the Internet or a computer network to a first domain that has an unrestrictive first cross-domain policy;

(D) means for receiving, at the suitably programmed computer, responsive to the submitting (C), a request module, wherein the source URL of the request module is identified as the first domain;

(E) means for causing the client application to execute, using the suitably programmed computer, the request module such that the request module is loaded into a first domain security sandbox, wherein

the first domain security sandbox is segregated from memory space in which the client application is run,

the first domain security sandbox is associated with, and limited to, programs that identify their source URL as being the first domain,

the request module is executed by the means for causing (E) such that the identity of the source URL of the request module is not altered or destroyed, and

the request module does not grant the client application the power to introspect the request module;

(F) means for generating, through the request module, using the suitably programmed computer, at a time when the request application is executing, a second request associated with the secure in-application transaction;

wherein the second request comprises (i) a credential for the client application, (ii) a transaction identifier that uniquely identifies the second request, and (iii) optionally, an identification of a user of the client application;

(G) means for submitting, using the suitably programmed computer, the second request for the secure in-application transaction over the Internet or the computer network to a second domain that has a second cross-domain policy that limits interaction between the second domain and programs external to the second domain to those external programs whose source URL is the first domain;

(H) means for receiving, responsive to the means for submitting (G), at the suitably programmed computer, a transaction module from the second domain wherein the source URL of the transaction module is identified as the second domain;

(I) means for causing, using the suitably programmed computer, the client application to execute the transaction module such that the transaction module is loaded into a second domain security sandbox within said memory, wherein

the second domain security sandbox is segregated from memory space in said memory in which the client application is run,

the second domain security sandbox is associated with, and limited to, programs that identify their source URL as being the second domain,

the transaction module is executed by the causing (I) such that the identity of the source URL of the transaction module is not altered or destroyed, and the transaction module does not grant the client application the power to introspect the validated transaction module;

(J) means for issuing, using the suitably programmed computer, from the transaction module while it is executing in the second domain security sandbox, a transaction call to a third domain, wherein the third domain has a cross-domain policy that limits interaction between the third domain and programs external to the third domain to those external programs whose source URL is the second domain;

(K) means for conducting, using the suitably programmed computer, a validated transaction between the third domain and the transaction module; and

(L) means for determining, using the suitably programmed computer, through the client application, by querying the first domain, whether the transaction was completed, thereby facilitating a secure transaction.

45. A computer system for facilitating a secure transaction, the computer system comprising:

one or more processing units;

a memory, coupled to at least one of the one or more processing units, the memory storing instructions that are executed by at least one of the one or more processing units, wherein the memory comprises;

a first domain characterized by a first cross-domain policy that is unrestrictive;

a second domain characterized by a second cross-domain policy that limits interaction between the second domain and programs external to the second domain to those external programs whose source URL is the first domain;

a third domain characterized by a third cross-domain policy that limits interaction between the third domain and programs external to the third domain to those external programs whose source URL is the second domain;

a database of valid application credentials;

a transaction database that is readable from the first domain, the second domain, and the third domain;

a request module;

a transaction module; and

instructions for;

(A) receiving, at the first domain, over the Internet or a computer network, a first request from a client application running on a client computer, wherein the first request is associated with a secure in-application transaction;

(B) providing, from the first domain, the request module to the client computer;

(C) receiving, at the second domain, over the Internet or the computer network, a second request from the request module running on the client computer, wherein the second request is associated with the secure in-application transaction and wherein the second request comprises (i) a credential for the client application, (ii) a transaction identifier that uniquely identifies the request, and (iii) optionally, an identification of a user of the client application, wherein the source URL of the request module complies with the second cross-domain policy;

(D) verifying the credential for the client application against the database of valid application credentials;

(E) keying the second request into the transaction database;

(F) providing, from the second domain, the transaction module to the client computer;

(G) receiving, at the third domain, a transaction call that originates from the transaction module executing on the client computer, wherein the source URL of the validated transaction module complies with the third cross-domain policy;

(H) conducting a validated transaction between the third domain and the transaction module running on the client computer;

(I) storing, at the third domain, a record of the completed transaction in the transaction database;

(J) receiving, at the first domain, a query from the client application running on the client computer as to whether the transaction has been completed, wherein the query includes the transaction identifier that uniquely identifies the request;

(K) determining, at the first domain, by looking up the transaction identifier in the transaction database, whether the transaction has been completed; and

(L) notifying, responsive to the receiving (J) and the determining (K), the client application running on the client computer of the status of the transaction.

46. The computer system of claim 45, wherein the secure in-application transaction is an in-game transaction to buy an in-game upgrade using an account associated with the identity of the user.

47. The computer system of claim 46, wherein the in-game upgrade is a level unlock, a purchase of virtual equipment, a purchase of a virtual special weapon, a purchase of a cheat, or a purchase of virtual currency.

48. The computer system of claim 45, wherein the client application is a social networking application, a financial services application, an accounting application, or a tax preparation application.

49. The computer system of claim 45, wherein the first domain, the second domain, and the third domain are hosted by the same server that is accessible to the client computer over the Internet or the computer network.

50. The computer system of claim 45, wherein the first domain, the second domain, and the third domain are each hosted by a separate server and are each accessible to the client computer over the Internet of the computer network.

51. The computer system of claim 45, wherein

the first domain is hosted by a first server,

the second domain is hosted by a second server,

the third domain is hosted by a third server,

the first server, the second server, and the third server are each accessible to the client computer over the Internet or the computer network,

the memory comprises a first memory resident in the first server, a second memory resident in the second server, and a third memory resident in the third server,

the first cross-domain policy and the request module are resident in the first memory of the first server,

the second cross-domain policy, the database of valid application credentials, and the unbranded transaction module are resident in the second memory of the second server, and

the third cross-domain policy is resident in the memory of the third server.

52. The computer system of claim 45, wherein the client application is a FLASH application and wherein the validated transaction module is a FLASH SWF application.

53. The computer system of claim 45, wherein the receiving (J), determining (K), and notifying (L) are repeated until the secure transaction is deemed completed.