Desarrollo / ROBLOX
ProcessReceipt en Roblox: plan para revisar la entrega de Developer Products
Separa la ventana de compra de la entrega, una compra nueva del procesamiento repetido y la ejecución de una función de su resultado. Define condiciones verificables antes de vender un producto de pago.
Define el resultado prometido #
Empieza con una promesa precisa: un paquete ficticio añade fichas de práctica al perfil guardado del jugador. Especifica cantidad, uso y qué debe conservarse después de volver a entrar. «Entregado» es ambiguo si solo observaste un mensaje temporal en pantalla.
Este artículo no contiene tienda operativa, identificadores reales, compras ni controlador listo. Prepara un plan para el creador. A y B son operaciones ficticias, no recibos reales de jugadores. No sustituyas una implementación verificada de ventas por este plan.
Separa ventana y entrega del servidor #
Mostrar la ventana solo inicia el recorrido visible del jugador. La documentación advierte que no se debe entregar un Developer Product mediante PromptProductPurchaseFinished: el evento por sí solo no demuestra una compra correcta. Revisa el recibo aparte de la respuesta del botón.
Registra observaciones distintas: ventana mostrada, recibo recibido, efecto confirmado y procesamiento reconocido ante la plataforma. No las juntes en un único éxito. Si solo se ve una animación del botón, el estado del perfil guardado sigue siendo desconocido.
Distingue producto y operación concreta #
ProductId identifica el producto procesado. PurchaseId distingue compras concretas. Dos recibos del mismo ProductId pueden ser compras independientes; repetir el mismo PurchaseId es otro caso que requiere revisar la operación ya tratada.
La primera pareja es A procesado inicialmente y A recibido otra vez. La segunda es A seguido de un nuevo B del mismo producto. El primer caso no debe repetir el efecto de A; el segundo necesita un resultado propio para B. Bloquear todo el producto tras una compra confunde estas tareas.
Abrir imagen a tamaño completo ↗No confundas ausencia de excepción y entrega #
Una llamada protegida puede terminar sin excepción aunque la función interior rechace o no entregue el objeto. Nuestra ficha propuesta incluye dos campos: si se ejecutó la llamada y si se confirmó el efecto. Son afirmaciones diferentes, no una sola bandera intercambiable.
Planifica un controlador que devuelve false sin excepción. La respuesta esperada debe reflejar la falta de entrega, no solo la ejecución correcta de la función. Examina por separado una excepción y un estado del jugador no disponible. Aquí no hay código que produzca esos resultados automáticamente.
Revisa juntos efecto y registro #
Las fichas persistentes necesitan hechos coherentes: efecto en el perfil y registro de compra procesada. Si cambia un saldo temporal pero no se guarda la finalización, el reintento puede encontrar un estado incompleto. Guardar la finalización antes del efecto puede marcar como terminada una entrega ausente.
Dibuja puntos de fallo entre etapas y describe recuperación para cada uno. Un recorrido normal correcto no prueba esos intervalos. Una bandera junto a un valor no persistente no demuestra entrega fiable. La arquitectura de guardado y repetición necesita revisión separada antes de vender.
Especifica el contrato de API elegido #
ProcessReceipt devuelve Enum.ProductPurchaseDecision. La documentación de MarketplaceService también incluye BindReceiptHandler con tipos de recibo propios y Enum.ReceiptDecision. No mezcles registro ni valores de retorno de ambos contratos en un mismo ejemplo.
Este material prepara una revisión de ProcessReceipt y no anuncia una migración obligatoria. Registra contrato utilizado, ubicación del controlador del servidor y responsable del registro. La documentación describe asignar ProcessReceipt una vez mediante un script del servidor; una sustitución inesperada desde otro script necesita investigación.
Incluye condiciones no disponibles #
Planifica un recibo con jugador ausente, producto desconocido o perfil todavía no preparado. Define para cada caso qué pruebas permiten confirmar la entrega. La falta de pruebas no debe convertirse en un mensaje seguro de «todo recibido».
Incluye también fallo de guardado y entrada posterior. Conserva contexto técnico mínimo y observación original sin publicar datos personales ni recibos reales en el sitio. No prometas un tiempo exacto de reintento: revisamos decisiones, no el calendario de procesamiento de la plataforma.
Revisa repetición y varios servidores #
Probar A dos veces en una sesión ayuda, pero no abarca procesamiento concurrente ni fallos entre efecto y guardado. El ejemplo de ProcessReceipt en la API señala una limitación relativa a fallos de datos entre servidores. Copiarlo no resuelve ese problema.
Enumera intentos paralelos, repetición tras un resultado de escritura desconocido y transformaciones repetidas de estado. No introduzcas efectos externos irreversibles en una operación repetible sin un protocolo revisado aparte. Son preguntas de implementación, no pruebas de que la tienda ficticia ya esté protegida.
Construye una matriz de resultados esperados #
Anota estado inicial, identidad de operación, cambio esperado y condición de confirmación. Empieza por A, A repetido y B nuevo. Añade perfil no disponible y escritura fallida. La tabla siguiente plantea preguntas de revisión, no resultados de pruebas pagadas.
El resultado esperado debe corresponder a la operación concreta y al efecto persistente. «No hay errores en Output» no responde sobre entregas duplicadas. Tras modificar el controlador, repite tanto el recorrido normal como el caso que motivó el cambio.
| Caso | Comprobar |
|---|---|
| Primer A | ¿Se confirma un efecto? |
| A repetido | ¿Se evita otro efecto de A? |
| B nuevo | ¿B tiene su propio efecto? |
| Escritura fallida | ¿Cómo resolver un resultado desconocido? |
Entrega pruebas y preguntas pendientes #
La ficha incluye tipo de producto, API elegida, modelo de perfil, escenario de reintento, observación y límites pendientes. Indica si la revisión fue conceptual, simulada o realizada en un juego de prueba independiente. Esos niveles no se confirman automáticamente entre sí.
Antes de vender hace falta una implementación verificada que conecte efecto y confirmación incluso ante fallos. Esta guía especifica esa tarea, pero no confirma que tus juegos estén listos para vender. No compres realmente para ilustrar un artículo ni presentes una hipótesis como resultado comprobado.
Abrir imagen a tamaño completo ↗| Campo | Registrar |
|---|---|
| Contrato | API elegida y valor de retorno |
| Operación | Producto y compra concreta |
| Efecto | Resultado persistente y repeticiones |
| Prueba | Tipo de revisión, observación y alcance |
Fuentes originales
Roblox Creator Hub — Developer ProductsRoblox Creator Hub — MarketplaceService API
